Problem with #define

[Harshit]

I am working on socket programming, encountered a new and strange
problem today.

I am using #define PORT 80, before main(), and I am calling PORT in one
of the statments inside main(), I get an error, I don't know why this
error is occuring. If i remove PORT in the statement and substitute it
by 80, my code works fine.


I am sure that #define works in C, any idea why my code is not
programming, i can also email my code if required.

Thanks

Harshit

 

[Merrill & Michele]

"Harshit"
I am working on socket programming, encountered a new and strange
problem today.

I am using #define PORT 80, before main(), and I am calling PORT in one
of the statments inside main(), I get an error, I don't know why this
error is occuring. If i remove PORT in the statement and substitute it
by 80, my code works fine.


I am sure that #define works in C, any idea why my code is not
programming, i can also email my code if required.

I believe this lies outside the scope of ISO C. Maybe one of the others
knows where to discuss this. MPJ

 

[Lawrence Kirby]

I am working on socket programming, encountered a new and strange
problem today.

Well C itself doesn't support socket programming, but your problem may be
(and sounds like) a language issue rather than relating to that.

I am using #define PORT 80, before main(), and I am calling PORT in one
of the statments inside main(), I get an error,

Saying "I get an error" isn't particularly useful. Detailing exactly what
error you get can and probably will be.

I don't know why this
error is occuring. If i remove PORT in the statement and substitute it
by 80, my code works fine.

Given the amount of detail here it is difficult to say much more than
"there is a bug in your code". Of course your compiler may have a bug but
at this stage that is a much less likely cause.

I am sure that #define works in C, any idea why my code is not
programming, i can also email my code if required.

Post your code here. Preferably post a MINIMAL but COMPLETE program that
demonstrates the problem, and cut and paste real code - it doesn't help
anybody if we end up just debugging transcription errors. If you can
come up with a version of problem code that doesn't use socket facilities
all the better, that might even help you figure out the cause.

Lawrence

 

[Richard Bos]

"Harshit"

Don't email code. Reduce it to the smallest compilable sample that still
shows the problem, then post it to the group. If you email it to someone
random and that person makes a mistake in his reply, who is going to
correct him? Here in comp.lang.c, though, you get free nit-picking by
professional nit-pickers from all over the world. And believe me, some
of us have elevated ye picking of ye nitte to a veritable art
Oh, and don't forget to include the _exact_ error you get ("It doesn't
work" is an error report I expect from users, not from my colleagues),
including whether it occurs at compile time or at run time, and under
what circumstances.

Without such information, it's impossible to give a reliable solution to
your problem. As a wild guess, though, maybe something else in your code
(an #included header, perhaps) is already #defining PORT?

I believe this lies outside the scope of ISO C.

Why ever would you think that? #define most definitely is ISO C, has
been so since C89, and AFAIK was K&R as well.

Richard

 

[Michael Coyne]

I am working on socket programming, encountered a new and strange problem
today.

I am using #define PORT 80, before main(), and I am calling PORT in one of
the statments inside main(), I get an error, I don't know why this error
is occuring. If i remove PORT in the statement and substitute it by 80, my
code works fine.

Just at a guess (you don't provide any code), perhaps you have written:

#define PORT 80;

instead of:
#define PORT 80

The former substitutes 80 and a semi-colon. The latter substitutes just
80.

If 80 works fine, and your #define is correct, then using PORT should just
work, so there must be something else going on. Posting some code would
help the group help you.


Michael

 

[Merrill & Michele]

"Richard Bos"

Don't email code. Reduce it to the smallest compilable sample that still
shows the problem, then post it to the group. If you email it to someone
random and that person makes a mistake in his reply, who is going to
correct him? Here in comp.lang.c, though, you get free nit-picking by
professional nit-pickers from all over the world. And believe me, some
of us have elevated ye picking of ye nitte to a veritable art
Oh, and don't forget to include the _exact_ error you get ("It doesn't
work" is an error report I expect from users, not from my colleagues),
including whether it occurs at compile time or at run time, and under
what circumstances.

Without such information, it's impossible to give a reliable solution to
your problem. As a wild guess, though, maybe something else in your code
(an #included header, perhaps) is already #defining PORT?


Why ever would you think that? #define most definitely is ISO C, has
been so since C89, and AFAIK was K&R as well.

The part that I thought was OT was any type of network activity. I would be
thrilled to find out that I'm completely wrong. You (Richard) posted about
a month back about the non-Standard nature of some activity being counted
along the horizon of a month. Do you recall the post? MP

 

[CBFalconer]

I am using #define PORT 80, before main(), and I am calling PORT in one
of the statments inside main(), I get an error, I don't know why this
error is occuring. If i remove PORT in the statement and substitute it
by 80, my code works fine.

I am sure that #define works in C, any idea why my code is not
programming, i can also email my code if required.

Many C define problems are the result of a terminal ; in the
define.

 

[Jens.Toerring]

The part that I thought was OT was any type of network activity. I would be
thrilled to find out that I'm completely wrong. You (Richard) posted about
a month back about the non-Standard nature of some activity being counted
along the horizon of a month. Do you recall the post? MP

The OP wasn't asking about anything network related but just about
some problems (s)he has with a #define directive - and that's about
as on-topic as you can get here.
Regards, Jens

 

[Keith Thompson]

Don't email code. Reduce it to the smallest compilable sample that still
shows the problem, then post it to the group.

[...]

(In this case, a compilable sample won't show the problem, assuming
that "I get an error" refers to a compilation failure.)

Agreed, but even posting just a couple of snippets of actual code,
along with the actual error message, is likely to be more useful than
a vague description. (By "actual code" I mean lines cut-and-pasted
from the actual source you're trying to compile, not re-typed.) For
example, if someone posted something like this:

] I am working on socket programming, encountered a new and strange
] problem today.
]
] I am using #define PORT 80, before main():
]
] #define PORT 80;
]
] and I am using PORT in one of the statements inside main():
]
] some_function(an_arg, PORT, another_arg);
]
] I get an error:
]
] foobar.c:42: error: parse error before ';' token
]
] I don't know why this error is occuring. If I remove PORT in the
] statement and substitute it by 80:
]
] some_function(an_arg, 80, another_arg);
]
] my code works fine.

we could have figured out the problem immediately. (I'm assuming, as
several other people here have, that it's a semicolon problem.)

This isn't always the case, of course. Sometimes nothing less than
the actual complete source file that you're feeding to the compiler
will do. But the more specific (not paraphrased) information you can
give us, the more likely we are to be able to help you.

 

[Merrill & Michele]

"Keith Thompson"

Don't email code. Reduce it to the smallest compilable sample that still
shows the problem, then post it to the group.

[...]

(In this case, a compilable sample won't show the problem, assuming
that "I get an error" refers to a compilation failure.)

Agreed, but even posting just a couple of snippets of actual code,
along with the actual error message, is likely to be more useful than
a vague description. (By "actual code" I mean lines cut-and-pasted
from the actual source you're trying to compile, not re-typed.) For
example, if someone posted something like this:

] I am working on socket programming, encountered a new and strange
] problem today.
]
] I am using #define PORT 80, before main():
]
] #define PORT 80;
]
] and I am using PORT in one of the statements inside main():
]
] some_function(an_arg, PORT, another_arg);
]
] I get an error:
]
] foobar.c:42: error: parse error before ';' token
]
] I don't know why this error is occuring. If I remove PORT in the
] statement and substitute it by 80:
]
] some_function(an_arg, 80, another_arg);
]
] my code works fine.

we could have figured out the problem immediately. (I'm assuming, as
several other people here have, that it's a semicolon problem.)

This isn't always the case, of course. Sometimes nothing less than
the actual complete source file that you're feeding to the compiler
will do. But the more specific (not paraphrased) information you can
give us, the more likely we are to be able to help you.

[SCOLDS BOY NOT TO TOUCH MOUSE]

I guess my contention is that the OP seems not to know where standard c
stops. This is critical to know in software development. Myself, I don't
know where c stops, but in clc I err on the side of strict interpretation.
MPJ