twitter: comp.lang.c - 25 new messages in 8 topics

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

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: Equality failure in <=.
http://groups.google.com/group/comp.lang.c/t/d49ffc1284d3557d?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Mar 24 2010 1:18 pm
From: Nick <3-nospam@temporary-address.org.uk>

"Robbie Hatley" <see.my.signature@for.my.contact.info> writes:

> Oh, and I see another bug in the output of my
> celsius-to-fahrenheit converer program, that I posted about
> here a few minutes ago (re. extra blank lines form printf).
>
> Again, the main lines are:
>
> printf(" Cels Fahr \n");
>
> for (Cels = CelsMin; Cels <= CelsMax; Cels += CelsInc)
> {
> Fahr = (((Cels*180.0)/100.0)+32);
> printf("%10.3f %10.3f\n\n", Cels, Fahr);
> }
>
> and the output for "celsfahr 40 41 0.001" is (sans extra blank lines):
>
> Cels Fahr
> 40.000 104.000
> 40.200 104.360
> 40.400 104.720
> 40.600 105.080
> 40.800 105.440
>
> Where is 41.000 ??? This table should have 6 entries, not 5,
> and the last line should read:
>
> 41.000 105.800
>
> Looks like the <= comparison is failing when Cels gets up to 41.000.
> I'm guessing it's somehow gets off a very small amount. Perhaps
> it's 41.00000001 when it gets compared to 41, so <= return false.
>
> I could change "Cels <= CelsMax" to "Cels <= (CelsMax+0.0001)".
> But that's a bit ugly. Any simpler way to do this?

Yes - count up in integers and work out the floating point values for
printing. But if ugly concerns you, look at those variable names,
capitalisation conventions and our long recent thread on testing
integers to see if they still equal variables.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

== 2 of 3 ==
Date: Wed, Mar 24 2010 1:59 pm
From: Eric Sosman

On 3/24/2010 4:03 PM, Robbie Hatley wrote:
> Oh, and I see another bug in the output of my
> celsius-to-fahrenheit converer program, that I posted about
> here a few minutes ago (re. extra blank lines form printf).
>
> Again, the main lines are:
>
> printf(" Cels Fahr \n");
>
> for (Cels = CelsMin; Cels<= CelsMax; Cels += CelsInc)
> {
> Fahr = (((Cels*180.0)/100.0)+32);
> printf("%10.3f %10.3f\n\n", Cels, Fahr);

Note the two count them 2 count them again II zwei due
deux newline characters ... You asked for blank lines, you
got blank lines -- well, duh.

> }
>
> and the output for "celsfahr 40 41 0.001" is (sans extra blank lines):
>
> Cels Fahr
> 40.000 104.000
> 40.200 104.360
> 40.400 104.720
> 40.600 105.080
> 40.800 105.440
>
> Where is 41.000 ??? This table should have 6 entries,[...]

In light of the 0.001 increment, I'd have expected about
a thousand lines. So I guess `+=' is also broken, huh?

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 3 of 3 ==
Date: Wed, Mar 24 2010 2:08 pm
From: "Robbie Hatley"

"Nick" wrote:

> ... count up in integers and work out the floating point values for
> printing...

Ok, could do that. In other programs.
In these two, I'm feeling lazy.
Just got them to work using the "+0.0001" thing.
I admit that the "integer" thing sounds like the technically
better way of doing it.

> ... look at those variable names ...

Hey, at least I didn't name them:

int a,b,c,d,e,f;

I've known programmers that do that. In production code,
for mid-sized corporations, no less. Grrr!

> ... capitalisation conventions ...

For some reason, Piers Anthony comes to mind. I see a flock
of birds, each shaped like a small letter c, rising from
the ground in front of me. I step back, startled, but my
programmer friend beside me says, "don't be alarmed, it's only
a flock of small C-gulls on their way to a Capitalization
Convention".

--
Cheers,
Robbie Hatley
lonewolf at well dot com
www dot well dot com slant tilde lonewolf slant

==============================================================================
TOPIC: Oops, wrong program source!
http://groups.google.com/group/comp.lang.c/t/8d049c1fe944b22b?hl=en
==============================================================================

== 1 of 5 ==
Date: Wed, Mar 24 2010 1:30 pm
From: "Robbie Hatley"

I inadvertantly included the source for my "Fahrenheit-to-Celsius"
program, not the "Celsius-to-Fahrenheit" one. Now I see why the
two programs behave differently! Too many files open in NoteTab;
I grabbed the wrong one. Sorry about the false alarm.

As is obvious from the source, the problem is an extra \n :

"Celsius-to-Fahrenheit":

printf(" Cels Fahr \n");

for (Cels = CelsMin; Cels <= CelsMax; Cels += CelsInc)
{
Fahr = (((Cels*180.0)/100.0)+32);
printf("%10.3f %10.3f\n\n", Cels, Fahr); /* Extra \n */
}

"Fahrenheit-to-Celsius":

printf(" Fahr Cels\n");

for (Fahr = FahrMin; Fahr <= FahrMax; Fahr += FahrInc)
{
Cels = (((Fahr-32)*100.0)/180.0);
printf("%10.3f %10.3f\n", Fahr, Cels); /* NO extra \n */
}

DOH!!!

--
Oops!
Robbie Hatley
lonewolf at well dot com
www dot well dot com slant tilde lonewolf slant

== 2 of 5 ==
Date: Wed, Mar 24 2010 1:40 pm
From: "Robbie Hatley"

"ImpalerCore" wrote:

> ... must be a typo somewhere ...

Close. I copy-n-pasted source code for wrong program altogether.
Sorry about the confusion. (See my post "Oops, wrong program source!").

--
Cheers,
Robbie Hatley
lonewolf at well dot com
www dot well dot com slant tilde lonewolf slant

== 3 of 5 ==
Date: Wed, Mar 24 2010 1:40 pm
From: Eric Sosman

On 3/24/2010 3:37 PM, Robbie Hatley wrote:
> Perhaps I'm making some newbie, bonehead mistake here, but
> I can't see what it is.[...]

Here's something I noticed:

> but what it *actually* prints is:
>
> Cels Fahr
> 40.000 104.000
>
> 40.200 104.360

... contrasted with the source line

> printf(" Fahr Cels\n");

Note that the column headings are desrever. Also, note
that while 40 Celsius is 104 Fahrenheit, 40 Fahrenheit is
4.44 Celsius, not 104: The direction of conversion is
also desrever. The output is not from some other program,
not from the source code you showed.

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 4 of 5 ==
Date: Wed, Mar 24 2010 1:41 pm
From: "bartc"

"Robbie Hatley" <see.my.signature@for.my.contact.info> wrote in message
news:zt6dnfJU_J_W7jfWnZ2dnUVZ_jadnZ2d@giganews.com...
>
> "bartc" wrote:
>
>> What happens when you leave out the "\n"?
>>
>> What about just doing printf ("abc\ndef\n"); ?
>>
>> Or puts("abc"); puts("def"); ?

> Ok, I'll test those. Here's a simple program:

> printf("abcd");
> printf("efgh");
> printf("ijkl");
...
> OUTPUT:
>
> abcdefghijkl
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> abc
> def
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> abc
> def
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> printf() isn't automatically inserting newlines.
> I didn't think it would, as other programs I've written
> and compiled on same compiler don't put them in.

OK, so printf() works as it should. So now, starting either with a simple,
working printf and adding to it, or the other way, try and see where the
problem creeps in.

These are suggestions (or perhaps put all of them in the loop; after which
one is there an extra newline?):

printf("<>\n");
printf("<%d>\n", (int)Fahr);
printf("<%10d>\n", (int)Fahr);
printf("<%10.3f>\n", Fahr);
printf("<%10.3f %10.3f>\n", Fahr, Cels);

Then that might give a clue as to what's causing the problem (as I can't
recreate it). Maybe a hidden control character in the format string (I
didn't notice one)?

--
Bartc

== 5 of 5 ==
Date: Wed, Mar 24 2010 1:42 pm
From: Eric Sosman

On 3/24/2010 4:40 PM, Eric Sosman wrote:
> [...]
> Note that the column headings are desrever. Also, note
> that while 40 Celsius is 104 Fahrenheit, 40 Fahrenheit is
> 4.44 Celsius, not 104: The direction of conversion is
> also desrever. The output is not from some other program,
> not from the source code you showed.

Too much editing, not enough proofreading: That final
sentence should have been "The output is from some other
program, not from the source code you showed."

--
Eric Sosman
esosman@ieee-dot-org.invalid

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

== 1 of 8 ==
Date: Wed, Mar 24 2010 1:34 pm
From: Joe Pfeiffer

Branimir Maksimovic <bmaxa@hotmail.com> writes:

> On Wed, 24 Mar 2010 12:02:13 -0600
> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
>>
>> No, a very small fraction of the virtual address space is mapped to
>> physical RAM.
>
> Hm , why then people have problem with Linux OOM killer, especially
> regarding Java GC. It has to pick targets more nicely not
> in random manner;) (and those machines have 4gb of ram)
> Problem is that I cn see no improvement over older hardware...
> and much less RAM...

I haven't had any problem with the OOM killer since the last time a
sysadmin forgot to turn swap on.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)

== 2 of 8 ==
Date: Wed, Mar 24 2010 2:04 pm
From: Keith Thompson

Branimir Maksimovic <bmaxa@hotmail.com> writes:
> On Wed, 24 Mar 2010 11:15:05 -0700
> Keith Thompson <kst-u@mib.org> wrote:
>> Branimir Maksimovic <bmaxa@hotmail.com> writes:
[...]
>> > But C memory model assumes absolute addressing.
>>
>> Not really, though I suppose it depends on what exactly you mean by
>> "absolute addressing".
>
> Array indexing in C is relative indexing. Relative pointers are ints,
> and absolute pointers are C pointers.

If you're talking about C, it's *very* important to remember that
pointers are not integers, and integers are not pointers.

It's possible to convert between pointer and integer types, but the
result of such a conversion (with the lone exception of converting a
constant 0 to a pointer type) is not portable.
[...]

> I think, malloc guarantees largest segment
> and ints are actually relative , short pointers into segment,
> while you can still use absolute pointers as bases.
> It's just a matter of realizing this.

Sorry, I don't know what "malloc guarantees largest segment"
is supposed to mean. The C standard, which is what defines the
behavior of malloc, doesn't talk about segments. C is carefully
designed to work on systems with either segmented or monolithic
addressing spaces.

> So for example if you have architecture base+ 12 bit offset like 360
> you can't malloc more than 4kb because of absolute+relativep.
> Since relativep in this case is 12 bits your size_t is limited to
> 4096 bytes.

A conforming hosted C implementation must support objects of at least
65535 bytes (in C99; C90 required 32767 bytes). So size_t must be at
least 16 bits. It's up to the compiler to generate whatever code is
needed to support this.

[...]

--
Keith Thompson (The_Other_Keith) kst-u@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"

== 3 of 8 ==
Date: Wed, Mar 24 2010 2:19 pm
From: glen herrmannsfeldt

In alt.sys.pdp10 Walter Bushell <proto@panix.com> wrote:
(snip)

> But ram is *so* cheap these days. Can you think of a reason for a
> million pointers at once? And that would be 0.008 gigabytes. Perhaps one
> needs to be that conscious for embedded work, but then one is not
> working with 64 bit addressing either.

RAM is cheap, but bandwidth isn't. Bigger pointers means more
data transfer to/from memory and slower running programs.

-- glen

== 4 of 8 ==
Date: Wed, Mar 24 2010 2:29 pm
From: Peter Flass

Mark Crispin wrote:
> On Wed, 24 Mar 2010, Nick Keighley posted:
>>>> 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"
>
> And, as you probably know, people who say such things are mindless
> cretins who, "in a civilized society, would be sent to a state
> laboratory for experimental purposes." Such people are boxing
> themselves into a corner; they just don't realize it yet.
>
> I will laugh myself silly when the latest & greatest CPU uses something
> other than numbers for pointers, and we can see a reprise of "all the
> world is not VAX."
>

I suppose you could have associative pointers.

== 5 of 8 ==
Date: Wed, Mar 24 2010 2:31 pm
From: Branimir Maksimovic

On Wed, 24 Mar 2010 21:19:42 +0000 (UTC)
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> In alt.sys.pdp10 Walter Bushell <proto@panix.com> wrote:
> (snip)
>
> > But ram is *so* cheap these days. Can you think of a reason for a
> > million pointers at once? And that would be 0.008 gigabytes.
> > Perhaps one needs to be that conscious for embedded work, but then
> > one is not working with 64 bit addressing either.
>
> RAM is cheap, but bandwidth isn't. Bigger pointers means more
> data transfer to/from memory and slower running programs.
>
> -- glen

Speaking to that I found that traversing linked list where
nodes are sorted by address is twice as fast than where
nodes are randomly sorted. Also found that quicksort that
is based on sequential memory access is much faster
than any sort based on random access. Same sort is
about 7 times faster when nodes are allocated behind
one another sorted by address and about 3-4 times
faster when there is larger gap between nodes.
That's why linked list sorts that change access order
are really bad thing, since after them traversing said list
is at least twice slower.
Eg random access radix sort of 5million nodes (512kb L@ cache dual
xeon ) is slower than first quick sort list by address, then
quick sort list by value by *sequential* access.
Of course that is if nodes are smaller ;)
That is for intel. Didn;t try amd.
Also tested initialization of 256 meg of ram
on modern quad xeon (external memory controller),and
home model dual athlon , same speed can you beleive?!
4 threads xeon , two threads athlon.
All in all nowadays it is more important to
pay attention on memory access patterns than anything else.

Greets

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

Sometimes online sometimes not

== 6 of 8 ==
Date: Wed, Mar 24 2010 2:36 pm
From: Peter Flass

Branimir Maksimovic wrote:
>
> I think, malloc guarantees largest segment
> and ints are actually relative , short pointers into segment,
> while you can still use absolute pointers as bases.
> It's just a matter of realizing this.
> So for example if you have architecture base+ 12 bit offset like 360
> you can't malloc more than 4kb because of absolute+relativep.
> Since relativep in this case is 12 bits your size_t is limited to
> 4096 bytes.

This is a false assumption. The displacement in the instruction is 12
bits, but you have an index register that's 2**31 bits, (2GB)

== 7 of 8 ==
Date: Wed, Mar 24 2010 2:41 pm
From: Branimir Maksimovic

On Wed, 24 Mar 2010 17:36:48 -0400
Peter Flass <Peter_Flass@Yahoo.com> wrote:

> Branimir Maksimovic wrote:
> >
> > I think, malloc guarantees largest segment
> > and ints are actually relative , short pointers into segment,
> > while you can still use absolute pointers as bases.
> > It's just a matter of realizing this.
> > So for example if you have architecture base+ 12 bit offset like 360
> > you can't malloc more than 4kb because of absolute+relativep.
> > Since relativep in this case is 12 bits your size_t is limited to
> > 4096 bytes.
>
> This is a false assumption. The displacement in the instruction is
> 12 bits, but you have an index register that's 2**31 bits, (2GB)

Thanks for explanation.

Greets!

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

Sometimes online sometimes not

== 8 of 8 ==
Date: Wed, Mar 24 2010 3:03 pm
From: Branimir Maksimovic

On Wed, 24 Mar 2010 14:04:54 -0700
Keith Thompson <kst-u@mib.org> wrote:

>
> If you're talking about C, it's *very* important to remember that
> pointers are not integers, and integers are not pointers.

Well digital computer is all numbers. array of 1' and 0's.
Remember, C was meant for assembler programmers.
I first learned basic than assembler on spectrum 48kb.
Then somehow C compiler was available for spectrum,
so when I saw ++ operator, immediately recognized
C as another assembler. Especially was fascinated that
you could crash computer with it same as in assembler.
Technically pointers are integers, but understanding
their meaning and usage on particular implementation
and exploiting it is not portable, of course.
But you *can* do it anyway if necessary and portability
is not of concern.

>
> It's possible to convert between pointer and integer types, but the
> result of such a conversion (with the lone exception of converting a
> constant 0 to a pointer type) is not portable.
> [...]
>
> > I think, malloc guarantees largest segment
> > and ints are actually relative , short pointers into segment,
> > while you can still use absolute pointers as bases.
> > It's just a matter of realizing this.
>
> Sorry, I don't know what "malloc guarantees largest segment"
> is supposed to mean. The C standard, which is what defines the
> behavior of malloc, doesn't talk about segments. C is carefully
> designed to work on systems with either segmented or monolithic
> addressing spaces.

Yes but, when you malloc you get chunk of raw memory
that can be indexed by integers of any type.
This maps 1-1 on assembler thinkology ;)
What about memory bank switching model?
Eg on amstrad cpc6128 there was 128kb of ram,
but 8 memory banks of 16kb each.
CPU could address maximum of 64kb.
64kb linear address space for apps and shadow OS
in another 64 kb, CP/M ?
There is *real* C compiler for it.
My second home computer btw ;)

>
> > So for example if you have architecture base+ 12 bit offset like 360
> > you can't malloc more than 4kb because of absolute+relativep.
> > Since relativep in this case is 12 bits your size_t is limited to
> > 4096 bytes.
>
> A conforming hosted C implementation must support objects of at least
> 65535 bytes (in C99; C90 required 32767 bytes). So size_t must be at
> least 16 bits. It's up to the compiler to generate whatever code is
> needed to support this.

Thanks for explanation.

Greets!

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

Sometimes online sometimes not

==============================================================================
TOPIC: How do I use a volatile variable as a boolean?
http://groups.google.com/group/comp.lang.c/t/5c535173bd7fc22f?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 24 2010 1:49 pm
From: Eric Sosman

On 3/24/2010 3:11 PM, mahdert wrote:
> On Mar 23, 3:45 pm, Eric Sosman<esos...@ieee-dot-org.invalid> wrote:
>> On 3/23/2010 1:49 PM, mahdert wrote:
>> [...]
>> --
>> Eric Sosman
>> esos...@ieee-dot-org.invalid

Please don't quote signatures.

> Thanks Eric,
> I like your approach and I have used it before. However, I was asking
> if the was a simple command in C that does this automatically.

There is not.

--
Eric Sosman
esosman@ieee-dot-org.invalid

==============================================================================
TOPIC: compiler bug / strange language feature
http://groups.google.com/group/comp.lang.c/t/bd415768eadcfc07?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Mar 24 2010 2:18 pm
From: Ben Bacarisse

"bartc" <bartc@freeuk.com> writes:

> "john" <john@nospam.com> wrote in message
> news:hodh2f$pfh$1@speranza.aioe.org...
>> Hello world:
>>
>> Gcc 4.4.3 generates a compiler error if I try to define a variable or
>> function called for.
>>
>> However, it seems to me that because of the special syntax of the for
>> keyword (parentheses with two semicolons), it is always possible to
>> distinguish unambiguously between for being used as a keyword and for
>> being used as a variable or function name.
>>
>> So why is it disallowed by Gcc? Is it a compiler bug or was this an
>> oversight when the C language was created?
>
> It was an oversight. You should of course be able to write:
>
> for (for;for;for); /* for statement */
> for (for,for,for); /* function call */
>
> as well as:
>
> if = while + for*int(goto);
>
> if you really want.

I have a feeling you are not serious, but if you are, consider syntax
aware editors. I don't really want an editor to have to parse the kind
of grammar you are (implicitly) suggesting. There are lots of
advantages to having a simple syntax and rather few to having a
variable called 'if'.

--
Ben.

== 2 of 4 ==
Date: Wed, Mar 24 2010 2:24 pm
From: Ben Bacarisse

ike@localhost.claranet.nl (Ike Naar) writes:

> In article <hodh2f$pfh$1@speranza.aioe.org>, john <john@nospam.com> wrote:
>>Gcc 4.4.3 generates a compiler error if I try to define a variable or
>>function called for.
>>However, it seems to me that because of the special syntax of the for
>>keyword (parentheses with two semicolons), it is always possible to
>>distinguish unambiguously between for being used as a keyword and for
>>being used as a variable or function name.
>
> It can be ambiguous:
>
> #define for(x) /* whatever */
>
> for(;;)
>
> Is this a for statement, or an invocation of the ``for'' macro with
> argument ``;;'' ?

I don't think allowing a function with the name 'for' has any effect
here. With that define, 'for(;;)' is unambiguously a macro
invocation regardless of whether there is function with that name
or not.

--
Ben.

== 3 of 4 ==
Date: Wed, Mar 24 2010 2:34 pm
From: "Scott Fluhrer"

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnzl1xzek1.fsf@nuthaus.mib.org...
> John Bode <jfbode1029@gmail.com> writes:
>> On Mar 24, 12:48 pm, Seebs <usenet-nos...@seebs.net> wrote:
>>
>> [snip]
>>
>>> So, it's not a bug, nor is it an oversight.
>>
>> Well, it *is* a bug, just not on the compiler's part.
>
> The "bug" in question is the inability to declare a variable named
> "for" because "for" is a keyword.

I believe what John is saying is that there's a bug in the program, not in
the compiler or the language definition...

--
poncho

== 4 of 4 ==
Date: Wed, Mar 24 2010 2:40 pm
From: Keith Thompson

"Scott Fluhrer" <sfluhrer@ix.netcom.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnzl1xzek1.fsf@nuthaus.mib.org...
>> John Bode <jfbode1029@gmail.com> writes:
>>> On Mar 24, 12:48 pm, Seebs <usenet-nos...@seebs.net> wrote:
>>>
>>> [snip]
>>>
>>>> So, it's not a bug, nor is it an oversight.
>>>
>>> Well, it *is* a bug, just not on the compiler's part.
>>
>> The "bug" in question is the inability to declare a variable named
>> "for" because "for" is a keyword.
>
> I believe what John is saying is that there's a bug in the program, not in
> the compiler or the language definition...

Ok, that makes sense.

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

== 1 of 1 ==
Date: Wed, Mar 24 2010 2:23 pm
From: Dr Malcolm McLean

On Mar 24, 5:58 pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> The scary thing? The average cost of a program crash was somewhere
> around $50k. This did not appear to factor into evaluations, though,
> because it was *customers* paying the $50k, not *developers*.
>
That's the way captialism works. The perceived value of the product,
not the actual value to customers, is what determines the price ypu
get for it. So if customers' accpunting system isn't good enough to
pick up the money he loses on crashes, he gets cheaper buggy software
rather than more expensive reliable stuff.
(This reaches an extreme when the customer is the consumer. Virtually
all the major consumer goods companies have far more equity in brands
than in physical plant. Often more money goes on marketing the product
than in manufacturing it. The associations that the marketing people
create between the product and the customers' aspirations almost never
have any basis in physical reality - the same beer can be a womans'
drink in Europe, a manly drink in America.)

==============================================================================
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:33 pm
From: Ben Bacarisse

"bartc" <bartc@freeuk.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.e23765669a04066f4532.20100324005256GMT.87r5na8rrr.fsf@bsb.me.uk...
>> "bartc" <bartc@freeuk.com> writes:
>>
>>> "Mark Hobley" <markhobley@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
>
>>> 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.
>
>> I have two CSV files I'm using at the moment whose longest lines have
>> 2201 and 2306 bytes and one old one with a 10155 byte line. It's hard
>> to put an upper limit on what is reasonable. Today's absurd it
>> tomorrow's "pah!".
>
> The text file format is being abused then. This sounds like an export
> from a database or spreadsheet. It's not text, unless you're using to
> reading pages 60 feet wide.

The structure is line-oriented. It should be read in text mode and a
line ends when you see '\n'. I call that a text file.

> If you already have code for a flexible getline(), then just
> it. Otherwise the next step up from a hard-coded size is a one-time
> allocated buffer which remains the same size. Bung 20KB (or 200KB) in
> there, and have done with it.

These solutions work, of course. I was just disputing the fact that
there is some maximum line length beyond which something stops being a
text file.

<snip>
--
Ben.

== 2 of 2 ==
Date: Wed, Mar 24 2010 2:57 pm
From: Moi

On Mon, 22 Mar 2010 22:54:42 +0000, 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?
>
> If I am doing this from scratch, what is the best practise for
> allocating a buffer size for the input line?
>
> 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?
>
> (My project is open source, so I can utilize GPL licenced code, if
> necessary.)
>
> C89 compatible code is preferred.
>
> Mark.

No need for limits.

1) Read the entire file into one buffer using fread, realloc() when needed.
2) Make a second pass on the buffer, find the line endings , handle \r\n,
replace them by \0, save the beginnings of the lines in an array of
pointers, realloc()ing when needed,
3) Make a third pass: process each line , searching for commas, replacing
them by \0, saving pointers to the beginnings, realloc()ing when needed.

Step 2 and 3 need to take care of quoting / escaping.
Step 1,2,3 _can_ be combined into one state machine.

HTH,
AvK

==============================================================================
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 3:00 pm
From: Ben Bacarisse

Willem <willem@turtle.stack.nl> writes:

> Willem wrote:
> ) Perhaps a semi-elegant solution could be made if you find a neat function
> ) that maps a grid position + size to the number that should go there in the
> ) spiral. An O(1) memory and speed function, mind.
> )
> ) int spiral(int x, int y, int size)
> ) {
> ) /* ... */
> ) }
> )
> ) I think a reasonably elegant solution exists.
> )
> ) The original program would then become simply:
> )
> ) for (y = 0; y < N; y++) {
> ) for (x = 0; x < N; x++) {
> ) printf("%04d", spiral(x, y, N));
> ) }
> ) printf("\n");
> ) }
> )
> ) One approach would be to find the quadrant, then find the distance
> ) from the edge, and then use some clever arithmetics to find the number.
> )
> ) Now that's a challenge!
> ) (I think I solved something similar some time ago, though).
>
> Yup, quite easy, and even semi-elegant:
>
> int spiral(int x, int y, int N)
> {
> int d, o = 2;
> /* Map down to up, left to right */
> if (x < y) {
> x = N-x-1;
> y = N-y-1;
> o -= 2;
> }
> /* Map right to up */
> if (x+y >= N) {
> int tx = x;
> x = y;
> y = N-tx-1;
> o -= 1;
> }
> /* Length of the line we're on */
> d = (N-(2*y)-1);
>
> return d*o + d*d - x + y;
> }
>
> This is based on the observation that the lower right diagonal
> is a succession of square numbers. The rest comes naturally.

Well, I got interested after all. The best I could come up with is
this:

int isquare(int x) { return x * x; }
int imax(int a, int b) { return a > b ? a : b; }
int imin(int a, int b) { return a < b ? a : b; }

int spiral(int x, int y, int N)
{
/* The expressions are simpler in terms of x+1. */
int X = x + 1;
if (N - X < y) {
int square = isquare(N - 2*imax(X, y));
if (X <= y)
return square + 3*y + X - 2*N;
else return square - 3*X - y + 2*N;
}
else return isquare(N - 2*imin(X, y)) - X + y;
}

This was done by inspection and algebra. I suspect the two
expressions returned in the inner 'if' can be written as one with some
suitable substitution of variables and more uses of imax and/or imin
but my interest started to flag.

Not to detract from your solution, but both of these fit my concern
that there'd be "fussy arithmetic". Yours probably reveals more about
the problem, but I don't think there is much structure to reveal.

--
Ben.

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

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

twitter

Wednesday, March 24, 2010

comp.lang.c - 25 new messages in 8 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts