| Newsgroups |
gmane.comp.db.tds.freetds |
| Message-ID |
<[email protected]> |
Hello James
In HP-UX FILENAME_MAX is 14.
I did the test and if the file name exceeds 15 (FILENAME_MAX + 1), the
error occurs
"James K. Lowden" <[email protected]>
Enviado por: [email protected]
09-12-2008 12:08
Por favor, responda a
FreeTDS Development Group <[email protected]>
Para
FreeTDS Development Group <[email protected]>
cc
Asunto
Re: [freetds] Freebcp coredump
[email protected] wrote:
>
> The problem is with the path of the format file. If you see params value
>
> in the gdb output, appears the following:
>
> formatfile = "/home/mysystem/fmt"
>
> interfacesfile = "ig.fmt\000\000\000\000\000\000\000\000"
>
> And the value of my format file parameter is /home/mysystem/fmt/
> emp_vig.fmt
>
> If run using the following parameters working properly:
>
> freebcp VW_GETDATA out res_eact.txt -f emp_vig.fmt -S$TDSQUERY -Uuser
> -Ppassword
>
> Do you know why this happens?
http://www.opengroup.org/onlinepubs/000095399/basedefs/stdio.h.html
http://www.delorie.com/gnu/docs/glibc/libc_652.html
I might.
BCPPARAMDATA in freebcp.h defines filenames as arrays of size
FILENAME_MAX+1. What is the value of FILENAME_MAX on HP/UX? Is is less
than the length of your filenames?
If so, we've tripped over a system limit, leading to my second question:
does HP/UX define strlcpy(3) in its standard C library? Because the fix
(assuming the above is correct) is one of two:
1. redefine formatfile et al. as char* instead of an array, and
dynamically allocate, or
2. use strlcpy to prevent overrunning the target buffer when copying the
names from argv.
Either one is technically correct, irrespective of GNU's warning.
In any case, you've provided a public service: even if this isn't the
problem, freebcp isn't checking its argument string lengths, and it
should. Thanks for pointing it out.
--jkl
_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds