comp.lang.c - 26 new messages in 13 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* Undefine a function from header file - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/8037a7e82b2ed522?hl=en
* Containers: The iterator object - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/662f02788cfa0c97?hl=en
* free scholarship for students-placement guaranteed - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/d619f9066ad8da96?hl=en
* Pointer comparisions of same type - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/82ec1e88374fdd51?hl=en
* How should I test for a null pointer? - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/ac6fdf22358cde1a?hl=en
* 16:32 far pointers in OpenWatcom C/C++ - 9 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/4728dadef590aafe?hl=en
* ◆⊙◆⊙◆ 2010 Cheap wholesale ED Hardy Long Sleeve, AF Long Sleeve, LV Long
Sleeve ect at http://www.fjrjtrade.com <Paypal Payment> - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/e08b1c2d90420e92?hl=en
* Hoping not to do the ugly - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/8055111701d1781b?hl=en
* Reading lines from a text file - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/5d6be78418b75b97?hl=en
* Cheap wholesale Armani Watch Omega Watch Rado Watch U-Boat Watch Zenith
Watch etc Paypal payment free shipping (www.vipchinatrade.com) - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c/t/2ecc3178b25f82b2?hl=en
* nothing much - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/3040e7c069dc5b93?hl=en
* 2 Challenges for the C Programmer in U... - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/2d55f4e5b7f533b6?hl=en
* Changing from && to || - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/412979e4b3c7cf45?hl=en

==============================================================================
TOPIC: Undefine a function from header file
http://groups.google.com/group/comp.lang.c/t/8037a7e82b2ed522?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 23 2010 11:58 pm
From: T Ryi

i've some old code from 1999. They have implemented their own loadavg
functions using static in X.c file.

Now i don't want to change the name of loadavg custom functions in
code to loadavg_custom.

But this loadavg is a function defined in stdlib.h. I need other
functions from stdlib.h , so i can't remove the declaration
#include<stdlib.h>

Is there anyway of saying the loadavg in stdlib.h to hide itself ? i
tried doing undef loadavg just after the declaration but it doesn't
work .

== 2 of 2 ==
Date: Wed, Mar 24 2010 1:15 am
From: Nick Keighley

On 24 Mar, 06:58, T Ryi <tryi...@gmail.com> wrote:

> i've some old code from 1999. They have implemented their own loadavg
> functions using static in X.c file.
>
> Now i don't want to change the name of loadavg custom functions in
> code to loadavg_custom.
>
> But this loadavg is a function defined in stdlib.h.

your stdlib is broken then

> I need other
> functions from stdlib.h , so i can't remove the declaration
> #include<stdlib.h>

it's a preprocessor directive not a declaration

> Is there anyway of saying the loadavg in stdlib.h to hide itself ?

the short answer is "no", but you might be able to do something nasty
with macros

> i
> tried doing undef loadavg just after the declaration but it doesn't
> work .

there is no "undef" for function declarations. Why don't you use a
different name for your replacement function?

==============================================================================
TOPIC: Containers: The iterator object
http://groups.google.com/group/comp.lang.c/t/662f02788cfa0c97?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 24 2010 12:31 am
From: jacob navia

ng2010 a écrit :
> "jacob navia" <jacob@spamsink.net> wrote in message
> news:ho39f3$n55$1@speranza.aioe.org...
>> In the last discussion we discussed how to do "GetNext" etc with
>> containers.
>>
>> I think it is important that the user code stays as abstract as
>> possible, without getting into the specifics of any container, as Mr
>> Becarisse said (if I remember correctly).
>>
>> Well, this could be done as follows. Please tell me what do you think.
>>
>> Thanks
>>
>> --------
>>
>>
>> All containers should be able to support the "GetNext" and the
>> "GetPrevious" functions.
>
> That, of course, is false. It is only true to you, for you don't know any
> better (apparently).

That, of course, is true. It is only false to you, for you don't know
any better (apparently).

Anybody can say that. If you disagree with something I write, it is not
enough to say "That is false" but you have to explain why you consider
it false.

You are unable to propose any arguments apparently.

> So, before you start in on details, you better
> discuss the alternative choices and why the above stated design is best.
>

Because in non sequential containers GetNext and GetPrevious should
traverse the sequence in some unspecified order that only guarantees
that all elements will be eventually visited. I wrote that inmy proposal
but since you did not get past the first sentence you did not read it.

HINT:

Read the propositions to the end, THEN reply. Thanks.

> (Aside: If this is a user group, it surely doesn't need first-time
> library builders acting like they have definitive library designs.
> "neophytes" WILL get sucked into the other neophyte's personal R&D, and
> surely C is "well-evolved" and not a research project in real usage (?)).
>

You are free to have your opinion, this is Usenet. Since (again) you do
not put any argumentation to substantiate your views, it is better to
leave them as what they are. Your personal opinion.

> (Aside 2: JN, if you think C is so great and good and readily usable, why
> don't you go actually USE it instead of trying to extend/modify it?

I use C every day. What is comic in your attacks is that you do not know
anything about me but somehow you think you can make statements like
"Why don't you actually USE C".

> Your
> actions say that C is not up to the task. And you are going on and on
> about FOUNDATIONAL issues with the language.

And why should I refrain from doing that?

Ahh of course, I forgot, excuse me: Because you said so.

> I was trying to be helpful
> when I said don't waste your time.)

Great! Then, you could be even more helpful and *explain* your point
ofview instead of just stating "This is wrong"...

You see? If you "explain" your views, we can discuss about them.

If you just say: "This is wrong" there is no discussion possible.

==============================================================================
TOPIC: free scholarship for students-placement guaranteed
http://groups.google.com/group/comp.lang.c/t/d619f9066ad8da96?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 24 2010 1:06 am
From: LLL <2ennel.0569@gmail.com>

http://123maza.com/75/expressions

==============================================================================
TOPIC: Pointer comparisions of same type
http://groups.google.com/group/comp.lang.c/t/82ec1e88374fdd51?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 24 2010 1:19 am
From: Nick Keighley

On 24 Mar, 06:54, T Ryi <tryi...@gmail.com> wrote:

>  I've a code like this
>  if(cp < buffer + sizeof(int) -1 ) ....
>
> Now buffer is unsigned int * , and cp is signed int *. Gcc gives a
> warning .
>
> I change it to
>  if(cp < (int *)(buffer + (sizeof(int) -1 ) )) ...
>
> Is there anything wrong with this cast ?   I'm assuming that casting
> between 2 pointers of same type but in different signedness

in other words *not* of the same type

> doesn't change anything . Is my assumption correct ?

it'll most likely work on most implementations but I think it is
technically Undefined Behaviour (UB). And if cp is not in the same
array ("object" is the technical term) as buffer then you'll /also/
get UB.

UB means the implementor is allowed by the C standard to anything he
damn well pleases (including working the way you expect it to).

==============================================================================
TOPIC: How should I test for a null pointer?
http://groups.google.com/group/comp.lang.c/t/ac6fdf22358cde1a?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Mar 24 2010 1:28 am
From: Nick Keighley

On 23 Mar, 17:50, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-03-23, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> > On 3/23/2010 12:17 PM, Seebs wrote:

> >> So, for instance, if people consistently point out mistakes I've made,
> >> rather than trying to declare that the language is wrong and shouldn't be
> >> like that, or calling them assholes, I generally just correct them and stop
> >> making those mistakes as often.
>
> >      It's said that the best response to a bug report is
> > "Thank you."
>
> Pretty much.  Sometimes it's "Thank you, but that's the intended behavior"
> or "Thank you, but your usage is incorrect", but in general, I try to err
> on the side of fixing anything that looks like a bug.

Thank you but...

...that's a well known problem
...its always done that
...why would anyone do that?
...customers don't do that
...that's bound to happen if you do that
...we'll change the handbook
...that's so old we should just close it

my time in system test wasn't wasted

== 2 of 3 ==
Date: Wed, Mar 24 2010 1:37 am
From: Nick Keighley

On 23 Mar, 20:12, Hamiral <hami...@hamham.com> wrote:
> Keith Thompson wrote:

> >     ptr = NULL; /* ptr has now been assigned */
> >     if (ptr == NULL) ... /* ? */
>
> You're nitpicking ;)
> Is it really necessary that I state that if a pointer is NULL I consider
> it's "not assigned", even if it has been assigned a NULL value ?

"if you call a tail a leg how many legs does a dog have? Four, because
calling a tail a leg doesn't mean it is a leg"

Lincoln, I believe

== 3 of 3 ==
Date: Wed, Mar 24 2010 2:03 am
From: Bob Doherty

On Wed, 24 Mar 2010 01:28:33 -0700 (PDT), Nick Keighley
<nick_keighley_nospam@hotmail.com> wrote:

>On 23 Mar, 17:50, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-03-23, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> > On 3/23/2010 12:17 PM, Seebs wrote:
>
>> >> So, for instance, if people consistently point out mistakes I've made,
>> >> rather than trying to declare that the language is wrong and shouldn't be
>> >> like that, or calling them assholes, I generally just correct them and stop
>> >> making those mistakes as often.
>>
>> >      It's said that the best response to a bug report is
>> > "Thank you."
>>
>> Pretty much.  Sometimes it's "Thank you, but that's the intended behavior"
>> or "Thank you, but your usage is incorrect", but in general, I try to err
>> on the side of fixing anything that looks like a bug.
>
>Thank you but...
>
>...that's a well known problem
>...its always done that
>...why would anyone do that?
>...customers don't do that
>...that's bound to happen if you do that
>...we'll change the handbook
>...that's so old we should just close it
>
>
>my time in system test wasn't wasted
>
>

The RSX develpment team for PDP-11 when confronted with something they
didn't wish to address, because the complainer was an idiot, or the
complainer was correct but for political reasons they couldn't do
anything about it, or for some other reason was a simple

...Noted.
--
Bob Doherty

==============================================================================
TOPIC: 16:32 far pointers in OpenWatcom C/C++
http://groups.google.com/group/comp.lang.c/t/4728dadef590aafe?hl=en
==============================================================================

== 1 of 9 ==
Date: Wed, Mar 24 2010 1:53 am
From: Nick Keighley

On 23 Mar, 20:56, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> In alt.sys.pdp10 Richard Bos <ralt...@xs4all.nl> wrote:
> (snip)
>
> > That crossposting was, for once, not asinine. It served as a nice
> > example why, even now, Leenux weenies are not correct when they insist
> > that C has a flat memory model and all pointers are just numbers.
>
> Well, you could also read the C standard to learn that.

but if you say that you get accused of language lawyering.
"Since IBM stopped making 360s no C program ever needs to run on such
a platform"

> There are additional complications for C on the PDP-10.

== 2 of 9 ==
Date: Wed, Mar 24 2010 2:39 am
From: Dann Corbit

In article <1e27d5ee-a1b1-45d9-9188-
63ab37398e9f@d37g2000yqn.googlegroups.com>,
nick_keighley_nospam@hotmail.com says...
>
> On 23 Mar, 20:56, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > In alt.sys.pdp10 Richard Bos <ralt...@xs4all.nl> wrote:
> > (snip)
> >
> > > That crossposting was, for once, not asinine. It served as a nice
> > > example why, even now, Leenux weenies are not correct when they insist
> > > that C has a flat memory model and all pointers are just numbers.
> >
> > Well, you could also read the C standard to learn that.
>
> but if you say that you get accused of language lawyering.
> "Since IBM stopped making 360s no C program ever needs to run on such
> a platform"

We have customers who are running their business on harware from the mid
1980s. It may sound ludicrous, but it if solves all of their business
needs, and runs solid 24x365, why should they upgrade?

> > There are additional complications for C on the PDP-10.

== 3 of 9 ==
Date: Wed, Mar 24 2010 2:48 am
From: raltbos@xs4all.nl (Richard Bos)

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> In alt.sys.pdp10 Richard Bos <raltbos@xs4all.nl> wrote:
>
> > That crossposting was, for once, not asinine. It served as a nice
> > example why, even now, Leenux weenies are not correct when they insist
> > that C has a flat memory model and all pointers are just numbers.
>
> Well, you could also read the C standard to learn that.

Yes, but Leenux weenies who post to comp.lang.c are frequently found to
be remarkably unable either to do that, or to believe that what they
read there applies to what it pleases them to call "the real world"
(i.e., Leenux-weenieworld).

Richard

== 4 of 9 ==
Date: Wed, Mar 24 2010 2:48 am
From: raltbos@xs4all.nl (Richard Bos)

Peter Flass <Peter_Flass@Yahoo.com> wrote:

> Branimir Maksimovic wrote:

> > Problem with standard C and C++ is that they assume flat memory
> > model.

Nonsense.

> I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as far
> as I know there's nothing in the C standard that assumes anything about
> pointers, except that they have to be the same size as int,

There is absolutely nothing in the C Standard that requires pointers to
have the size of int, or even the size of anything whatsoever, except
that
- void pointers and char pointers shall have the same representation
(and therefore size) as one another - _not_ necessarily as any other
kind of pointer, though since void pointers must be able to be freely
convertible from and to other object pointers, it takes a perverted
implementation to make them _smaller_ than other object pointers (but
perversion, though not advised, is allowed implementation authors);
- pointers to const <foo> must have the same representation as pointers
to <foo> and vice versa, and ditto for volatile and restrict;
- all pointers to struct must have the same representation, and all
pointers to union (but struct pointers need not be the same as union
pointers; again, it would usually be silly not to have them be, but
it's allowed).
Nothing about ints there.

Richard

== 5 of 9 ==
Date: Wed, Mar 24 2010 2:57 am
From: Branimir Maksimovic

On Wed, 24 Mar 2010 09:48:12 GMT
raltbos@xs4all.nl (Richard Bos) wrote:

> Peter Flass <Peter_Flass@Yahoo.com> wrote:
>
> > Branimir Maksimovic wrote:
>
> > > Problem with standard C and C++ is that they assume flat memory
> > > model.
>
> Nonsense.
>
Well, technically this is not nonsense. There are no built in
features to portably accommodate different memory models.
Problem is that sizeof(char*) can be realistically
in some situation 4 bytes in other 8 bytes , and
third 2 bytes even in same function.
Is this allowed by standard C and C++?
If this is allowed then yes, C and C++ does not assume
flat memory model.

Greets!

--
http://maxa.homedns.org/

Sometimes online sometimes not

== 6 of 9 ==
Date: Wed, Mar 24 2010 3:18 am
From: Branimir Maksimovic

On Wed, 24 Mar 2010 01:53:56 -0700 (PDT)
Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:

> On 23 Mar, 20:56, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > In alt.sys.pdp10 Richard Bos <ralt...@xs4all.nl> wrote:
> > (snip)
> >
> > > That crossposting was, for once, not asinine. It served as a nice
> > > example why, even now, Leenux weenies are not correct when they
> > > insist that C has a flat memory model and all pointers are just
> > > numbers.
> >
> > Well, you could also read the C standard to learn that.
>
> but if you say that you get accused of language lawyering.
> "Since IBM stopped making 360s no C program ever needs to run on such
> a platform"
>
Problem is that segmented memory model is much better when working
with 64 bit address space. Flat memory model wastes to much
RAM. It would be better for standard C and C++ to provide appropriate
pointer semantics in order to keep memory usage optimal.
What is use of 64 bit flat pointers when you can actually
just load segment base and work with offsets?
Actually compilers are forced to use maximum possible
size of pointer in order to cover all possible sizes,
because of memory model forced by C and C++.
This is not about segmented flat model.
It is about different addressing modes even in flat model.
It seems that besides flat memory model C and C++ assumes
always absolute addressing pointers.
Technically this limitation can be easily circumvented
if different sizes of pointers to same type are allowed.
Ok, void* should be maximum size, but there is no reason
you can't have different sizes for char*.

Greets!

--
http://maxa.homedns.org/

Sometimes online sometimes not

== 7 of 9 ==
Date: Wed, Mar 24 2010 3:51 am
From: Peter Flass

Richard Bos wrote:
> Peter Flass <Peter_Flass@Yahoo.com> wrote:
>
>> Branimir Maksimovic wrote:
>
>>> Problem with standard C and C++ is that they assume flat memory
>>> model.
>
> Nonsense.
>
>> I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as far
>> as I know there's nothing in the C standard that assumes anything about
>> pointers, except that they have to be the same size as int,
>
> There is absolutely nothing in the C Standard that requires pointers to
> have the size of int, or even the size of anything whatsoever, except
> that
> - void pointers and char pointers shall have the same representation
> (and therefore size) as one another - _not_ necessarily as any other
> kind of pointer, though since void pointers must be able to be freely
> convertible from and to other object pointers, it takes a perverted
> implementation to make them _smaller_ than other object pointers (but
> perversion, though not advised, is allowed implementation authors);
> - pointers to const <foo> must have the same representation as pointers
> to <foo> and vice versa, and ditto for volatile and restrict;
> - all pointers to struct must have the same representation, and all
> pointers to union (but struct pointers need not be the same as union
> pointers; again, it would usually be silly not to have them be, but
> it's allowed).
> Nothing about ints there.
>

Yes, I've gotten a few corrections on this;-) I guess what I was
thinking of is a statement I've heard several times that lots of
existing C code *assumes* sizeof(ptr) = sizeof(int), and breaks when
this isn't true.

== 8 of 9 ==
Date: Wed, Mar 24 2010 3:57 am
From: Branimir Maksimovic

On Wed, 24 Mar 2010 06:51:09 -0400
Peter Flass <Peter_Flass@Yahoo.com> wrote:

> Richard Bos wrote:
> > Peter Flass <Peter_Flass@Yahoo.com> wrote:
> >
> > Nothing about ints there.
> >
>
> Yes, I've gotten a few corrections on this;-) I guess what I was
> thinking of is a statement I've heard several times that lots of
> existing C code *assumes* sizeof(ptr) = sizeof(int), and breaks when
> this isn't true.

It is strange that one have to check for size of pointer, because
you can always implement segmented/relative addressing model,
buy using shorts/ints/longs/longlongs as pointers
into array(segment) and implement far near pointer thing,
without problem thanks to malloc and brilliant design
of C arrays that can map to 1-1 to real segment.
Technically besides void* (as a base) there is no real use of any
other type of C or C++ pointer in portable code.
Ints would do perfectly. No need to check for sizes of pointers
at all ;)

Greets

--
http://maxa.homedns.org/

Sometimes online sometimes not

== 9 of 9 ==
Date: Wed, Mar 24 2010 4:16 am
From: Ahem A Rivet's Shot

On Wed, 24 Mar 2010 10:57:37 +0100
Branimir Maksimovic <bmaxa@hotmail.com> wrote:

> On Wed, 24 Mar 2010 09:48:12 GMT
> raltbos@xs4all.nl (Richard Bos) wrote:
>
> > Peter Flass <Peter_Flass@Yahoo.com> wrote:
> >
> > > Branimir Maksimovic wrote:
> >
> > > > Problem with standard C and C++ is that they assume flat memory
> > > > model.
> >
> > Nonsense.
> >
> Well, technically this is not nonsense. There are no built in
> features to portably accommodate different memory models.
> Problem is that sizeof(char*) can be realistically
> in some situation 4 bytes in other 8 bytes , and
> third 2 bytes even in same function.
> Is this allowed by standard C and C++?

Having the underlying addressing mechanism of the processor use
different sizes of address for different contexts does not require a C
implementation to follow suit. Nothing requires C pointers to be addresses
they could be larger structures that include enough information for the
compiler to generate an address of the appropriate type when needed (or
otherwise retrieve the data being pointed to).

> If this is allowed then yes, C and C++ does not assume
> flat memory model.

It doesn't - all that C requires of pointers is that they can be
dereferenced, converted to void pointers and back again, and that adding
and subtracting integers works within certain well defined limits. Nothing
requires them to be machine addresses.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

==============================================================================
TOPIC: ◆⊙◆⊙◆ 2010 Cheap wholesale ED Hardy Long Sleeve, AF Long Sleeve, LV
Long Sleeve ect at http://www.fjrjtrade.com <Paypal Payment>
http://groups.google.com/group/comp.lang.c/t/e08b1c2d90420e92?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 24 2010 1:56 am
From: "www.fjrjtrade.com"

Cheap wholesale Long Sleeve

Cheap wholesale Armani Long Sleeve

Cheap wholesale G-STAR Long Sleeve

Cheap wholesale A&F Long Sleeve

Cheap wholesale Christan Audigier Long Sleeve

Cheap wholesale D&G Man Long Sleeve

Cheap wholesale Ecko Long Sleeve

Cheap wholesale ED Hardy Long Sleeve

Cheap wholesale Gucci Long Sleeve

Cheap wholesale Lacoste Long Sleeve

Cheap wholesale LV Long Sleeve

Cheap wholesale Nike Long Sleeve

Cheap wholesale Ralph Lauren POLO Long Sleeve

http://www.fjrjtrade.com

==============================================================================
TOPIC: Hoping not to do the ugly
http://groups.google.com/group/comp.lang.c/t/8055111701d1781b?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 24 2010 2:07 am
From: Nick Keighley

On 23 Mar, 21:53, c...@tiac.net (Richard Harter) wrote:

> This is a request for suggestions about a good way to do
> something.  The context is message passing.  The program(s) in
> question are divided into system code and user code.  User code
> consists of lots of autonomous elements that pass messages back
> and forth.  System code takes care of scheduling user code
> elements and handling the mechanics of message handling.
>
> There is a lot more to it than that, but that will do for
> context.  The prototype for a user code element that responds to
> a message currently looks like this:
>
>     void  response_function(sigil_s, void *, packet_s);
>
> The first and third arguments are typedefs for structs.  There
> are very good reasons why they aren't pointers to structs so
> don't go there.  For sundry reasons we don't want the fields of
> these structs visible to users.  (Keepen der sticky Fingers offen
> die Buttons).  
>
> User code interacts with system code via an API; the game is to
> get users to access structs via API calls.
>
> One way to do this is to create structs that look like this:
>
>    struct pseudo_sigil {char[n]};  /* n is sizeof(sigil_s) */
>
> In the API we can do something charming like:
>
>    sigil_s foo;
>    ...
>    foo = (sigil_s)bar;  /* bar is a pseudo_sigil struct */
>
> This is mildly cumbersome but I think it can be made to work
> except for one small glitch - we don't want to hard code the size
> of sigil_s et al.

I don't see how you avoid it. Depending of course on what you mean by
"hard code". At compile time the value of n must be known no matter
how you wrap it up.

How have you got into the state where you trust your users so little?
Would you be better off with a less low level language where you have
more control over what they do?

> I can think of a couple of ways to hide the sizeof using
> preprocessor magic but ugly is as ugly does.
>
> If anybody has any good suggestions, I would be delighted to hear
> them.

== 2 of 2 ==
Date: Wed, Mar 24 2010 2:48 am
From: raltbos@xs4all.nl (Richard Bos)

cri@tiac.net (Richard Harter) wrote:

> void response_function(sigil_s, void *, packet_s);
>
> The first and third arguments are typedefs for structs. There
> are very good reasons why they aren't pointers to structs so
> don't go there. For sundry reasons we don't want the fields of
> these structs visible to users. (Keepen der sticky Fingers offen
> die Buttons).

Those are more or less contradictory requirements. All solutions are
going to be ugly, because passing information without passing
information (i.e., prevaricating to your caller) _is_ ugly. Sorry.

Richard

==============================================================================
TOPIC: Reading lines from a text file
http://groups.google.com/group/comp.lang.c/t/5d6be78418b75b97?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 24 2010 2:09 am
From: James Harris

On 22 Mar, 22:54, markhob...@hotpop.donottypethisbit.com (Mark Hobley)
wrote:
> I want to read a text file a line at a time from within a C program. Are there
> some available functions or code already written that does this or do I need
> to code from scratch?

Yes, I wrote a piece of code to do just that and incorporated in it
helpful input from other people on comp.lang.c.

http://codewiki.wikispaces.com/xbuf.c

The section on reading lines shows what you are looking for and also
why the code was needed, i.e. problems with other solutions.

James

== 2 of 2 ==
Date: Wed, Mar 24 2010 2:49 am
From: Nick Keighley

On 23 Mar, 23:47, "bartc" <ba...@freeuk.com> wrote:
> "Mark Hobley" <markhob...@hotpop.donottypethisbit.com> wrote in message
>
> news:i29l77-jpv.ln1@neptune.markhobley.yi.org...
>
> >I want to read a text file a line at a time from within a C program. Are
> >there
> > some available functions or code already written that does this or do I
> > need
> > to code from scratch?
>
> > If I am doing this from scratch, what is the best practise for allocating
> > a buffer size for the input line?
>
> I just use a fixed size, big enough for text files that are line-oriented.
>
> I've just checked and I'm using a 2KB buffer, but it could be much higher if
> memory allows.
>
> If the lines are longer than that sort of size, the file probably isn't
> line-oriented and could do with a different approach. (Or might use a
> different newline convention from that expected. Either way, you have a file
> that is not in the right format.)

and what does your program do?

> > I guess open the file, scan once to determine the buffer size, then rewind
> > and
> > start reading. Has this already been done or do I need to code this from
> > scratch?
>
> From files that might work (although pedants might say that by the second
> read, someone could have written a longer line to the file). From devices
> such as consoles I'm not sure that would work.
>
> --
> Bartc
>
> --- news://freenews.netfront.net/ - complaints: n...@netfront.net ---

==============================================================================
TOPIC: Cheap wholesale Armani Watch Omega Watch Rado Watch U-Boat Watch Zenith
Watch etc Paypal payment free shipping (www.vipchinatrade.com)
http://groups.google.com/group/comp.lang.c/t/2ecc3178b25f82b2?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 24 2010 2:35 am
From: yoyo

Cheap wholesale A.Lange&Sohne Watch <Paypal payment>
Cheap wholesale Armani Watch
Cheap wholesale Audemar Piguet Watch
Cheap wholesale Bape Watch
Cheap wholesale Baume&Mercier Watch <www.vipchinatrade.com>
Cheap wholesale Bell&Ross Watch
Cheap wholesale Blancpain Watch <free shipping>
Cheap wholesale Breguet Watch
Cheap wholesale Breit Ling Watch
Cheap wholesale BRM Watch <www.vipchinatrade.com>
Cheap wholesale burberry Watch
Cheap wholesale Bvlgari Watch <free shipping>
Cheap wholesale Cartier Watch<www.vipchinatrade.com>
Cheap wholesale Chanel Watch <Paypal payment>
Cheap wholesale Chopard Watch
Cheap wholesale Concord Watch
Cheap wholesale Corum Watch <free shipping>
Cheap wholesale D&G Watch
Cheap wholesale Dewitt Watch <www.vipchinatrade.com>
Cheap wholesale Ebel Watch
Cheap wholesale Ferrari Watch
Cheap wholesale Franck Muller Watch
Cheap wholesale Girard Perregaux Watch <free shipping>Cheap wholesale
Givenchy Watch
Cheap wholesale Glashutte Watch<www.vipchinatrade.com>
Cheap wholesale Graham Watch
Cheap wholesale Gucci Watch <free shipping>
Cheap wholesale Guess Watch
Cheap wholesale Hamilton Watch <Paypal payment>
Cheap wholesale Hermes Watch
Cheap wholesale Hublot Watch
Cheap wholesale IWC Watch
Cheap wholesale Jacob&Co Watch <www.vipchinatrade.com>
Cheap wholesale Jaeger Lecoultre Watch
Cheap wholesale Kappa Watch
Cheap wholesale Longines Watch <free shipping>
Cheap wholesale LV Watch
Cheap wholesale Montblanc Watch
Cheap wholesale Movado Watch <www.vipchinatrade.com>
Cheap wholesale Omega Watch
Cheap wholesale Oris Watch <Paypal payment>
Cheap wholesale Paket Philippe Watch
Cheap wholesale Panerai Watch
Cheap wholesale Parmigiani Fleurier Watch <free shipping>
Cheap wholesale Piaget Watch
Cheap wholesale Porsche Design Watch <www.vipchinatrade.com>
Cheap wholesale Prada Watch
Cheap wholesale Rado Watch<Paypal payment>
Cheap wholesale Rolex Man Watch
Cheap wholesale Romain Jerome Titanic-Dna Watch <free shipping>
Cheap wholesale Tag Heuer Watch
Cheap wholesale Tissot Watch <www.vipchinatrade.com>
Cheap wholesale Titoni Watch
Cheap wholesale Tudor Watch <Paypal payment>
Cheap wholesale U-Boat Watch
Cheap wholesale Vach. Constantine Watch
Cheap wholesale Zenith Watch <www.vipchinatrade.com>

==============================================================================
TOPIC: nothing much
http://groups.google.com/group/comp.lang.c/t/3040e7c069dc5b93?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 24 2010 2:59 am
From: Nick Keighley

On 24 Mar, 00:49, Keith Thompson <ks...@mib.org> wrote:
> Phred Phungus <Ph...@example.invalid> writes:
> > Eric Sosman wrote:
> >> On 3/21/2010 4:01 PM, Phred Phungus wrote:

> >>> An interesting read. Beyond what Ben and Lawrence had to comment, I was
> >>> curious about this language:
>
> >>>  > The implementation had to document its choice ....
>
> >>> Implementations have to document something? How general is this
> >>> requirement?

I'm not sure what you mean. Section F.3 of the 1989 ANSI Standard (the
ISO Standard numbers things slightly differently) lists the
implementaion defined behaviours. There are about 14 sub-sections
covering everything from identifier length to the behaviour of the
register directive to various twisty corners of the library.

> >>     See Section 3.4.1.
>
> >   3.4.1
> > 1 implementation-defined behavior
> >   unspecified behavior where each implementation documents how the
> > choice is made.  EXAMPLE An example of implementation-defined behavior
> > is the propagation of the high-order bit when a signed integer is
> > shifted right.
>
> > So, if an implementation *doesn't* document how propagation occurs in
> > the above example, is the behavior just unspecified or does it get
> > bumped to undefined, as non-entities are?
>
> If an implementation doesn't document the behavior in a case
> where the standard requires it to do so, then the implementation
> is non-conforming, and the standard has nothing to say about it
> other than that it's non-conforming.

shoot. So when we asked our compiler supplier to send us the
documentaion and he sent us the ANSI stanbdard instead we didn't have
a conforming implementaion! On the other hand I still have a copy of
the ANSI Standard...

> In practice, of course, people aren't typically going to reject an
> implementation entirely just because some particular feature isn't
> properly documented.  The point is that the standard doesn't specify
> a fallback position for implementations that fail to conform to it.

==============================================================================
TOPIC: 2 Challenges for the C Programmer in U...
http://groups.google.com/group/comp.lang.c/t/2d55f4e5b7f533b6?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 24 2010 4:20 am
From: Moi

On Tue, 23 Mar 2010 09:27:25 -0700, BruceS wrote:

> On Mar 23, 9:47 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>> On Mar 22, 2:29 pm, Chinmay S <2.6kilohe...@gmail.com> wrote:
>>
>> > If...then...else... A simple
>> > challenge.http://2600hertz.wordpress.com/2010/03/18/if-then-else/
>>
>> I haven't looked at any answers yet, but did you forget the parentheses
>> in the if? If so, it is simple:
>>
>> #include <stdio.h>
>>
>> #define else
>>
>> int main()
>> {
>> if ("condition")
>> printf ("Hello-");
>> else
>> printf("World!!");
>>
>> }
>
> Like a lot of puzzles, this one didn't make the rules as clear as it
> should have, but the clear intent was to replace only the condition, not
> other parts of the statement. The solution is quite simple, of course.
> I don't claim to be great at stating puzzles either, but I would have
> said it more like:
>
> -----
> In the following code, what should be put after "if" to make the code
> produce the output "Hello-World!!"?
>
> if
> printf ("Hello-");
> else
> printf("World!!");
> -----
>
> This would avoid the confusion about "condition" being part of the code,
> rather than being what needs to be replaced. I've seen a lot of puzzles
> with similarly misleading or poorly stated conditions. I'm fairly
> confident that the intent of the puzzle was as I represent, but maybe
> not. Chinmay S may wish to clarify.

if (fork() || sleep(1) )

/* not standard :-) */

AvK

==============================================================================
TOPIC: Changing from && to ||
http://groups.google.com/group/comp.lang.c/t/412979e4b3c7cf45?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 24 2010 4:31 am
From: James Harris

In a macro I have a function of the form

(a) >= (b) && f(a, b)

and I think it may be incorrect. The idea is that the function is
called only if a >= b but the expression should also return true if a
< b. I guess what I have will return false so I'm thinking to change
it to

(a) < (b) || f(a, b)

So, if a < b it will return true and not call the function. If a >= b
it will call the function and return the result of the function call.

Have I got the change right?

James

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en