integer
in [Unix Programming]
|
From: Nicolas George on 23 Feb 2010 04:57 Ersek, Laszlo wrote in message <hchVcKujY$Fu(a)ludens>: > gcc -g3 allows gdb to print macro names, too. > > ----v---- > Level 3 includes extra information, such as all the macro definitions > present in the program. Some debuggers support macro expansion when you > use -g3. > ----^---- AFAIK, it does not enables to print them, only use them. For example: #define FOO 42 #define NOT_FOO 43 void frobnicate(int value) { if(value == FOO) score++; } (indented for compactness, not my usual style) Then tracing frobnicates gives: Breakpoint 1, frobnicate (value=42) at tm.c:8 But you can ask: (gdb) p value - FOO $1 = 0 Compiling with -g rather than -g3 gives: No symbol "FOO" in current context. But enums go further: typedef enum { FOO = 42, NOT_FOO } foo_or_not; void frobnicate(foo_or_not value) { gives: Breakpoint 1, frobnicate (value=FOO) at tm.c:7 This is logical: in the second program, we explicitly tell the compiler that value is related to the FOO constant, by giving it the foo_or_not type. In the first program, the compiler or the debugger can only guess based on the fact that value is later compared to FOO, and that can not be expected from it.
From: Ersek, Laszlo on 23 Feb 2010 06:19 In article <4b83a69d$0$17805$426a74cc(a)news.free.fr>, Nicolas George <nicolas$george(a)salle-s.org> writes: > Ersek, Laszlo wrote in message <hchVcKujY$Fu(a)ludens>: >> gcc -g3 allows gdb to print macro names, too. >> >> ----v---- >> Level 3 includes extra information, such as all the macro definitions >> present in the program. Some debuggers support macro expansion when you >> use -g3. >> ----^---- > > AFAIK, it does not enables to print them, only use them. For example: Yes, I mixed them up with enums, sorry! > This is logical: in the second program, we explicitly tell the compiler that > value is related to the FOO constant, by giving it the foo_or_not type. In > the first program, the compiler or the debugger can only guess based on the > fact that value is later compared to FOO, and that can not be expected from > it. Yes, there could be a thousand macros evaluated to 42 by the preprocessor, so mapping back from (int)42 is not unique (and even if it was unique it would probably make no sense to hunt for possible macro substitutions for any int value queried in the debugger). Thanks, lacos
From: Keith Thompson on 23 Feb 2010 14:22 Phred Phungus <Phred(a)example.invalid> writes: > I'm curious about the following description: > > #include <unistd.h> > > long > pathconf(const char *path, int name); > > > > DESCRIPTION > [snip] > ... > > _PC_NAME_MAX > The maximum number of bytes in a file name. > > _PC_PATH_MAX > The maximum number of bytes in a pathname. > > Why are these ultimate two values integers? Why not? What would you expect them to be? -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Phred Phungus on 23 Feb 2010 14:49 Keith Thompson wrote: > Phred Phungus <Phred(a)example.invalid> writes: >> I'm curious about the following description: >> >> #include <unistd.h> >> >> long >> pathconf(const char *path, int name); >> >> >> >> DESCRIPTION >> > [snip] >> ... >> >> _PC_NAME_MAX >> The maximum number of bytes in a file name. >> >> _PC_PATH_MAX >> The maximum number of bytes in a pathname. >> >> Why are these ultimate two values integers? > > Why not? What would you expect them to be? > I guess the point is that I've seen many unix calls like this where one of the fields is a bunch of things like _OPTION_1 or _OPTION_2 . Apparently the system defines them as ints, because this is all I can find: $ gcc e4.c -E -dM >text5.txt #define _PC_PATH_MAX _PC_PATH_MAX -- fred
From: Keith Thompson on 23 Feb 2010 16:24 Phred Phungus <Phred(a)example.invalid> writes: > Keith Thompson wrote: >> Phred Phungus <Phred(a)example.invalid> writes: >>> I'm curious about the following description: >>> >>> #include <unistd.h> >>> >>> long >>> pathconf(const char *path, int name); >>> >>> >>> >>> DESCRIPTION >>> >> [snip] >>> ... >>> >>> _PC_NAME_MAX >>> The maximum number of bytes in a file name. >>> >>> _PC_PATH_MAX >>> The maximum number of bytes in a pathname. >>> >>> Why are these ultimate two values integers? >> >> Why not? What would you expect them to be? >> > > I guess the point is that I've seen many unix calls like this where > one of the fields is a bunch of things like _OPTION_1 or _OPTION_2 > . Apparently the system defines them as ints, Yes, because that's what the function requires as an argument. > because this is all I > can find: > > $ gcc e4.c -E -dM >text5.txt > > #define _PC_PATH_MAX _PC_PATH_MAX The man page should be enough to tell you that _PC_PATH_MAX is some kind of integer expression, probably constant, and that you don't really need to know how it's defined; it's sufficient to know that its value is distinct from the values of the other _PC_* constants. Pass it as the second argument to pathconf, and it should do what it's supposed to do. If you're curious, the output of "gcc -E -dM" probably isn't the best thing to look at. Here's what I just did (results on your system may vary): $ grep -rl _PC_PATH_MAX /usr/include /usr/include/bits/confname.h $ view /usr/include/bits/confname.h A look at confname.h shows that _PC_PATH_MAX is an enumeration constant, and it's additionally defined as a macro that expands to itself. I suspect the _PC_* constants were defined as enumeration constants because it's convenient, and the macros are there because POSIX requires them and/or because it allows you to write #ifdef _PC_PATH_MAX ... #endif As far as I can tell, asking why these values are integers isn't really a very meaningful question; the only direct response I could give is "Why not? What would you expect them to be?". So what is it you really want to know? -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: command line options for child process Next: Stylistic questions on UNIX C coding. |