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: Efficency and the standard library
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
==============================================================================

== 1 of 4 ==
Date: Mon, Feb 15 2010 12:03 pm
From: "wolfgang.riedel"

On 12 Feb, 19:53, spinoza1111 <spinoza1...@yahoo.com> wrote:
> Perhaps we really need a string finder and a replacer which would
> encapsulate left to right, right to left, and what to do on overlap.
>
> However, the traditional way to do this can be slow, since it involves
> creating a "table" of occurrences.
>
> But two independent processes, a source and a sink, would handle the
> problems nicely.

How so?
Your first cite is a design question -
which your second doesn't even scratches!

(I know, you're with me on this:
Rexx's changestr(needle, hay, newneedle) is an implementation -
of one choice)

Wolfgang

== 2 of 4 ==
Date: Mon, Feb 15 2010 12:12 pm
From: Willem

Chris M. Thomasson wrote:
) Because an empty source and an empty comparand match each other?
)
)
) Humm... Perhaps my line of thinking on this matter is just way off somewhere
) deep in the heart of moron land. Thanks for challenging me on it Willem! I
) will think this over.

Well, the thing is that the comparand is matched against substrings of the
source. And the question then becomes: Is the empty string a substring of
all possible strings ?

I can see where you're coming from, but mathematically speaking, it's an
anomaly. You probably had to special-case it in your code, and that's
usually a good indication that it is also a special case in the
specification.

PS: If you don't account for an empty comparand, then the result is the
replacement string repeated indefinitely. Sort of like how division by
zero is often thought to yield infinity.

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

== 3 of 4 ==
Date: Mon, Feb 15 2010 12:30 pm
From: "io_x"

I@
"spinoza1111" <spinoza1111@yahoo.com> ha scritto nel messaggio
news:546b7d87-4d82-4e93-bdfb-dd9e5aca9e02@s36g2000prf.googlegroups.com...

@Perhaps i don't understand all the written text i see ( i think it is 50%)
@but it seems to me not justly you speak against peaceful and
@what show very educated and helpful people: Keith

On Feb 14, 4:09 am, Keith Thompson <ks...@mib.org> wrote:
> Seebs <usenet-nos...@seebs.net> writes:
>
> [...]
>
> > That said, I do like the idiom
> > size_t lenstr(char *string) {
> > char *end = string;
> > while (*end++)
> > ;
> > return end - string;
> > }
>
> > Not that it's likely to make a noticeable difference. Or that it's likely
> > worth it when obviously the standard library one will be fine.
>
> Note that ``end - string'' yields a value of type ptrdiff_t, a signed
> type which very likely can't represent all values of type size_t.
>
> This is unlikely to be an issue in practice. On typical 32-bit
> systems, problems show up only for strings longer than 2 gigabytes,
> and even then the properties of 2's-complement arithmetic are likely
> to result in the correct answer anyway.
>
> But all this analysis, resulting in the conclusion that it will
> almost certainly work properly, becomes unnecessary if you just
> use strlen().
>
> --
> Keith Thompson (The_Other_Keith) ks...@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"

Kenny McCormack, thou should'st be here at this hour:
For Kiki is in finest Form, posting pompously and sour:
Exhibiting ersatz Learning, and utter Pedantry:
He concludes, after "all this analysis" that "almost certainly"
That "it" (Seebie's shit) will yeah right..."work properly".
But for "123" Seebie's code grinds out to the amazement of the Crowd
The number...the number...FOUR, to dismay that is loud.
Whilst we the putative Trolls do dance amidst burning Tyres
Laughing our hairy Asses off at the doom of Pedantry's pretentious
spires!

== 4 of 4 ==
Date: Mon, Feb 15 2010 3:38 pm
From: richard@cogsci.ed.ac.uk (Richard Tobin)

In article <%ohen.82897$Fe4.9664@newsfe21.iad>,
Chris M. Thomasson <no@spam.invalid> wrote:

>Why exactly do you need to assert that `target' is not a zero length string?

...

>I would also assume that:
>
>replace("Hello World!", "", "XXX");
>
>would produce a string equal to "Hello World!".

There are an arbitrary number of instances of the empty string before
the first character, between each pair of characters, and after the
last character. Even if it does only one replacement at each position
it will still produce

XXXHXXXeXXXlXXXlXXXoXXX XXXWXXXoXXXrXXXlXXXdXXX!XXX

(I didn't type that in, I type "Hello World!" and used the editor's
replace function with the arguments "" and "XXX".)

>I would assume that:
>
>replace("", "", "Hello World!");
>
>will spit out a string equal to "Hello World!".

That's reasonable, since it replaces lots of empty strings with
empty strings.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

==============================================================================
TOPIC: substring finding problem!
http://groups.google.com/group/comp.lang.c/t/cf9bd97208e0c3a3?hl=en
==============================================================================

== 1 of 5 ==
Date: Mon, Feb 15 2010 12:04 pm
From: Willem

Seebs wrote:
) On 2010-02-15, Chris M. Thomasson <no@spam.invalid> wrote:
)> I just cannot really understand why you are trying to avoid `string.h' in
)> all cases. I mean, if you wanted to re-implement `strstr()', well, that's
)> fine. However, I don't see a real need to roll your own version of
)> `strlen()' or `memcpy()'. I mean, how can you do better than a good
)> implementation of the standard C library? An implementation of `memcpy()'
)> will most likely be using processor specific instructions that provide a
)> level of efficiency that cannot be reached with 100% pure portable C code.
)
) I have no clue. I also don't see why he thinks my posts about his buggy
) code have anything to do with the time or effort it takes to get this done.
) When he proposed a more general problem than the one my original effort
) solved, I posted a proposed solution, which took about ten minutes to write,
) and in which one bug was found so far. (It went into an infinite loop if you
) had it matching a zero-length substring.) I fixed that, and it's done. So
) far as I can tell, it works for all inputs that don't exhaust memory or
) size_t or something similar, and is otherwise unexceptional because the
) task is fundamentally a very trivial one.

I wouldn't call matching a zero-length substring a bug, really. More of an
oversight in the specification. It's comparable to dividing by zero.

The reason I enjoyed coding it up without using string.h functions is
because it's an academic challenge/puzzle. Not a hard one, mind.

== 2 of 5 ==
Date: Mon, Feb 15 2010 12:05 pm
From: Seebs

On 2010-02-15, Willem <willem@snail.stack.nl> wrote:
> I wouldn't call matching a zero-length substring a bug, really. More of an
> oversight in the specification. It's comparable to dividing by zero.

My code's behavior was a bug, though -- bad inputs shouldn't cause an
infinite loop.

> The reason I enjoyed coding it up without using string.h functions is
> because it's an academic challenge/puzzle. Not a hard one, mind.

It's interesting, and the recursive strategy is fascinating.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 3 of 5 ==
Date: Mon, Feb 15 2010 12:27 pm
From: Tim Streater

On 15/02/2010 18:08, spinoza1111 wrote:

[snip]

> And yes. A solution WITH BUGS can be more intelligent than a clean
> one. A solution that TAKES A LONG TIME can likewise be better than one
> that doesn't. I was also prepared to concede victory to Willem despite
> his one character identifiers because of the beauty of his idea: use
> recursion and not a data structure.

Yes - VICTORY! - that's what we need. Doubtless you will be increasing
the chocolate ration from 30gm/week to 20gm/week in the near future too.

--
Tim

"That the freedom of speech and debates or proceedings in Parliament
ought not to be impeached or questioned in any court or place out of
Parliament"

Bill of Rights 1689

== 4 of 5 ==
Date: Mon, Feb 15 2010 12:35 pm
From: "Chris M. Thomasson"

"Seebs" <usenet-nospam@seebs.net> wrote in message
news:slrnhnjagd.fm3.usenet-nospam@guild.seebs.net...
> On 2010-02-15, Willem <willem@snail.stack.nl> wrote:
>> I wouldn't call matching a zero-length substring a bug, really. More of
>> an
>> oversight in the specification. It's comparable to dividing by zero.
>
> My code's behavior was a bug, though -- bad inputs shouldn't cause an
> infinite loop.
>
>> The reason I enjoyed coding it up without using string.h functions is
>> because it's an academic challenge/puzzle. Not a hard one, mind.
>
> It's interesting, and the recursive strategy is fascinating.

Yes, I agree that the solution based on recursion is neat. However, any
recursive function tends to make me worry about blowing the stack. Perhaps I
worry to much!

;^)

== 5 of 5 ==
Date: Mon, Feb 15 2010 1:49 pm
From: Walter Banks

"Chris M. Thomasson" wrote:

> Yes, I agree that the solution based on recursion is neat. However, any
> recursive function tends to make me worry about blowing the stack. Perhaps I
> worry to much!

As much as I like recursive solutions for many things including most of the
parsers I have written.

There are some application areas where recursion is avoided. Most of the
automotive bugs 10 or 15 years ago had a stack depth component and most
code is now written with predictable run time requirements.

Regards

Walter..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

==============================================================================
TOPIC: A bit resistant to disruption
http://groups.google.com/group/comp.lang.c/t/a5ddb7c1aa07c7e5?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Feb 15 2010 12:54 pm
From: Francois Grieu

Thad Smith wrote about the following problem [I added more notes, since
the problem has been partially misunderstood by some]

Disclaimer: This is a hard problem, only minimally disguised into
something on-topic for comp.lang.c

You are programming a C99 conforming freestanding implementation (e.g. a
microprocessor device programmed in C, but we can't use <stdio.h> or
otherwise store data on disk). Disruption (reset or power off/on cycle)
can occur at *ANY* time without advance warning, and stops whatever
operation is underway. The program is re-executed from main() after a
disruption.

The objective is to implement a single bit resistant to disruption,
accessed using two procedures to be written:
int bRead(void); // Return 0 or 1 according to bit state
void bToggle(void); // Change the state of the bit

and such that these two properties are met:
a) The bit is stable in the absence of Toggle. That is, the result given
by any two undisrupted bRead() is the same unless bToggle() was invoked
in-between.
b) The bit is changed by Toggle. That is, the result given by any two
undisrupted bRead() is different if bToggle() was invoked exactly once
in-between and no disruption occurred during that execution of bToggle().

Note: The bit is therefore unspecified from the invocation of bToggle()
until the end of this bToggle() if it is undisrupted, or otherwise until
the end of the next undisrupted bRead(). This is the only definition of
"bit resistant to disruption" worth of interest.

The only way to store information across disruptions is using a number
of independent physical EEPROM cells, designated by index j. Access to
the EEPROM cells is by the following three functions. The properties
stated for theses functions apply for any fixed non-negative integer j
less than the number of cells, and "for that cell" is implied everywhere.

// Read a designated EEPROM cell; always returns 0 or 1.
extern int eRead(int j);

// Erase a designated EEPROM cell.
// After undisrupted eErase, the cell is "erased" and eRead returns
// 0 until eProgram is invoked (regardless of invocation of eErase
// and disruptions)
extern void eErase(int j);

// Program a designated *ERASED* EEPROM cell.
// After undisrupted eProgram, eRead returns 1 until eErase is invoked
// (regardless of disruptions)
// Programming a cell that is not "erased" cause undefined behavior.
extern void eProgram(int j);

An EEPROM cell can be left neither erased nor programmed by a disrupted
eErase unless that cell was already erased, or by a disrupted eProgram.
For a cell in such halfway state, eRead returns a value specified only
to be 0 or 1. That otherwise unspecified value may in particular change
after disruption (due e.g. to uncontrollable random noise and/or
temperature and/or voltage drift in the hardware used by eRead), even
though the sate of cells is unchanged by disruption or/and eRead.

Note: if a cell is not erased (left in a halfway state or programmed),
an eProgram of that cell is prohibited. A workaround is to use the
following rather than eProgram():
void mySafeProgram(int j)
{
eErase(j);
eProgram(j);
}

Before the first run, all EEPROM cells have been erased. eRead, eErase,
and eProgram terminate unless a disruption occurs, assuming constraints
on j and eProgram are met. bRead and bToggle must similarly terminate
unless a disruption occurs.

Can it be done? If yes, what is the minimum number of cells needed? Give
a proof.

Depending on the answer, try to minimize the expected failure rate or
maximize the expected LED flash rate in the following use case:
*/

#define NCELLS 10 // number of cells

extern void sLed(int x); // 0: LED on green then off
// 1: LED on red then off.
extern int eRead(int j); // Read a cell.
extern void eErase(int j); // Erase a cell to 0.
extern void eProgram(int j); // Program an erased cell to 1.

int bRead(void); // Return 0 or 1 according to bit state.
void bToggle(void); // Change the state of the bit.

// Declarations, and the code for bRead/bToggle, go here

int main(void)
{
int vState;
vState = bRead();
while(1)
{
sLed(vState);
bToggle();
vState = !vState;
}
return 0;
}

/*
Assume eProgram, eErase, sLed each last 1 second; everything else is
comparatively instant; a disruption occurs with odds p each second;
unspecified eRead values are assigned at random with mean 0.5; the LED
is off following disruption; a failure is a violation of the
requirement: if a disruption occurs with the LED on in some color, then
the first time the program lights a LED it must be with that color.

Note: any bRead/bToggle conforming to a) b) works in this test program,
and any bRead/bToggle making this test program working can be changed
into bRead/bToggle2 conforming to a) b), by defining bToggle2 as:

void bToggle2(void)
{
(void)bRead();
bToggle();
}

Notice that disruption without warning is the standard under which most
real-life hardware actually operates (with the exception of systems with
physical protection against adversarial reset and a power reserve with
means to sense imminent power loss), even though this is often left out
of the specification. And that real disruption-surviving media (EEPROM,
Flash, CDRW, though not battery-backed SRAM) do have the limitation that
read after interrupted change of state sometime gives an unstable
result. While "programming a cell that is not erased cause undefined
behavior" is not the rule, it can exist due to a poorly specified API,
an overcautious hardware specification, or in some cases due to tue
hardware limitations.

The problem is derived from actual requirements in a Smart Card. This is
neither homework, nor an attempt to gather brainpower for free: I'm the
author of the problem and have conclusively determined the feasibility,
with a concise proof. A similar problem "A bit in bottles" is in
rec.puzzles, some of the replies contain answers, and I committed mine.
http://groups.google.com/group/rec.puzzles/browse_thread/thread/ab892b3cf88af0de

Francois Grieu

> First, this is an uninteresting problem because if a power failure
> occurs during a toggle attempt, the restored state gives no
> information at all.

Is the prefix "UN" intended? Thad Smith shows continued INterest, and
I'm grateful to him for that.

> I'm taking another stab at the problem, based on more analysis and
> an understanding of possible use. Thanks to Daniel Giaimo for
> finding a problem in the earlier proposal.
>
> Let's assume the variable has three state categories: s1, s2, and t.
> s1 and s2 are stable states (will not change spontaneously).
> Other values are transition values. If the variable is read in a
> state t, the variable is then changed to s1 or s2.
>
> This can be used to perform a consistent database state update:
> Assume initially database copy A is consistent and dbstate=s1
> (database A is valid). To update, make an updated copy B. At
> this point both A and B are consistent. Set dbstate=s2 (database B
> is valid). Move B to A. Set dbstate=s1.
>
> If power is lost while dbstate is being changed, both database
> copies are valid, so restoring the state to either stable state
> results in a consistent database.
>
> We just need to make sure that s1 and s2 are always stable when
> an modification is in progress on copy A or B.
>
> In the following list of sequential states, each of the four bits
> are independently erasable and writable (normally implemented in
> separate bytes).
>
> Bit
> dbstate dcba Stable bits
> s1 0001 ca
> t1a 0011 da
> t1b 0111 db
> t1c 0110 db
> s2 0010 ba
> t2a 1010 cb
> t2b 1011 dc
> t2c 1001 ca
> (s1) 0001 ca
>
> To go from state s1 to s2 or s2 to s1, we first re-erase the last
> bit erased, then sequentially write the variable to the following
> transition and stable states, changing a single bit at a time.
>
> When reading dbstate, if value is s1 or s2, return the value.
> If value is txa or txb, erase and rewrite the last bit set,
> pr*o*cede to the next stable state. If value is txc, re-erase the
> last bit erased, then procede to the next stable state.

Going from t2b to t2c, disruption occurs while we erase "b".
On restart, state is "10?1". We read it as "1011" that is t2b.
While we "erase the last bit set", that is "a", disruption occurs.
On restart, state is "10??". We read it as "1010" that is t2a.
[notice the "Stable bits: cb" condition is not met]
While we "erase the last bit set", that is "d", disruption occurs.
On restart, state is "?0??" [or maybe "?0?0" is we have been prudent
and erased "a" right after seeing it as 0].
We read that as "0010" and assume state s2.
Before we make any change/call to bToggle(), disruption occurs
and we read the same state as "0001" and assume state s1, this is
a violation of requirement a.
[is we have erased "a" we will read "0000" and I guess we
will next move to s1 and be equally busted]

> If power fails when in a transition state, a reading of the state
> with the above rules will restore dbstate to a stable value.

Not so, see above.

> Multiple interrupts during a restoration can cause the state values
> to go from t1b to t1a to s1, but it doesn't revert any further

Right, unless I err.

> (similar for t2b to t2a to s2).

I don't think so..

[snip]

I plan to post my answer by the end of the week.

Francois Grieu

==============================================================================
TOPIC: OT: Proper use of PRNGs
http://groups.google.com/group/comp.lang.c/t/6c1d292648f8f699?hl=en
==============================================================================

== 1 of 6 ==
Date: Mon, Feb 15 2010 12:57 pm
From: raltbos@xs4all.nl (Richard Bos)

Keith Thompson <kst-u@mib.org> wrote:

> William Hughes <wpihughes@hotmail.com> writes:
> > On Feb 10, 6:27 pm, Keith Thompson <ks...@mib.org> wrote:
> [...]
> >> "We must do something. This is something. Therefore, we must do this."
> >> -- Antony Jay and Jonathan Lynn, "Yes Minister"
> >
> > I love this quote. Which show is it from?
>
> If you mean which episode, I have no idea; I've never actually seen
> the show.

If you are at all interested in British politics - or even in Great
Britain, or in politics - do so as soon as you can.

Richard

== 2 of 6 ==
Date: Mon, Feb 15 2010 1:12 pm
From: Richard Heathfield

William Hughes wrote:
> On Feb 10, 6:27 pm, Keith Thompson <ks...@mib.org> wrote:

<snip>
>
>> "We must do something. This is something. Therefore, we must do this."
>> -- Antony Jay and Jonathan Lynn, "Yes Minister"
>
> I love this quote. Which show is it from?

"Yes Prime Minister", Series Two, Episode 5, "Power to the People".

Sir Arnold Robinson: "He's suffering from politicians' logic."
Sir Humphrey Appleby: "'Something must be done; this is something;
therefore, we must do it'."

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 3 of 6 ==
Date: Mon, Feb 15 2010 1:56 pm
From: Peter Nilsson

ralt...@xs4all.nl (Richard Bos) wrote:
> Keith Thompson <ks...@mib.org> wrote:
> > William Hughes <wpihug...@hotmail.com> writes:
> > > On Feb 10, 6:27 pm, Keith Thompson <ks...@mib.org> wrote:
> > [...]
> > >> "We must do something. This is something. Therefore,
> > >> we must do this."
> > >> -- Antony Jay and Jonathan Lynn, "Yes Minister"
> > >
> > > I love this quote. Which show is it from?
> >
> > If you mean which episode, I have no idea; I've never
> > actually seen the show.
>
> If you are at all interested in British politics - or even
> in Great Britain, or in politics - do so as soon as you can.

And if you like Nigel Hawthorn, get a hold the 79 TV movie
"The Knowledge".

--
Peter

== 4 of 6 ==
Date: Mon, Feb 15 2010 2:25 pm
From: Keith Thompson

Richard Heathfield <rjh@see.sig.invalid> writes:
> William Hughes wrote:
>> On Feb 10, 6:27 pm, Keith Thompson <ks...@mib.org> wrote:
>
> <snip>
>>
>>> "We must do something. This is something. Therefore, we must do this."
>>> -- Antony Jay and Jonathan Lynn, "Yes Minister"
>>
>> I love this quote. Which show is it from?
>
> "Yes Prime Minister", Series Two, Episode 5, "Power to the People".
>
> Sir Arnold Robinson: "He's suffering from politicians' logic."
> Sir Humphrey Appleby: "'Something must be done; this is something;
> therefore, we must do it'."

You mean I've had the quote wrong all these years?

Initially I didn't have an attribution, because I wasn't sure
where it came from; I had just heard it somewhere. It's possible
I got it from somewhere else, and the writers of "Yes Minister"
either adapted it from the same source or came up with something
similar independently.

--
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"

== 5 of 6 ==
Date: Mon, Feb 15 2010 2:32 pm
From: Richard Heathfield

Keith Thompson wrote:
> Richard Heathfield <rjh@see.sig.invalid> writes:
>> William Hughes wrote:
>>> On Feb 10, 6:27 pm, Keith Thompson <ks...@mib.org> wrote:
>> <snip>
>>>> "We must do something. This is something. Therefore, we must do this."
>>>> -- Antony Jay and Jonathan Lynn, "Yes Minister"
>>> I love this quote. Which show is it from?
>> "Yes Prime Minister", Series Two, Episode 5, "Power to the People".
>>
>> Sir Arnold Robinson: "He's suffering from politicians' logic."
>> Sir Humphrey Appleby: "'Something must be done; this is something;
>> therefore, we must do it'."
>
> You mean I've had the quote wrong all these years?

Yup. Sorry.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 6 of 6 ==
Date: Mon, Feb 15 2010 4:08 pm
From: William Hughes

On Feb 15, 5:12 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> William Hughes wrote:
> > On Feb 10, 6:27 pm, Keith Thompson <ks...@mib.org> wrote:
>
> <snip>
>
>
>
> >> "We must do something. This is something. Therefore, we must do this."
> >> -- Antony Jay and Jonathan Lynn, "Yes Minister"
>
> > I love this quote. Which show is it from?
>
> "Yes Prime Minister", Series Two, Episode 5, "Power to the People".

Thanks - William Hughes

==============================================================================
TOPIC: Knowing the implementation, are all undefined behaviours become
implementation-defined behaviours?
http://groups.google.com/group/comp.lang.c/t/4f8b56b26018cf4e?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Feb 15 2010 1:28 pm
From: pacman@kosh.dhis.org (Alan Curry)

In article <hl83o2$aos$1@news.eternal-september.org>,
Michael Tsang <miklcct@gmail.com> wrote:
|-----BEGIN PGP SIGNED MESSAGE-----
|Hash: SHA1
|
|Deferencing a NULL pointer is undefined behaviour, but, on Linux, the
|program crashes with SIGSEGV. So, the behaviour of derefencing a NULL
|pointer is defined to "crash the program with SIGSEGV".

Are you sure?

Compile this with and without -DUSE_STDIO and explain the results.

Both branches ask the system to do the exact same thing: fetch a byte from
the address indicated by NULL, and write it to the standard output.

#include <stdio.h>
#include <unistd.h>

int main(void)
{
#ifdef USE_STDIO
if(fwrite(NULL, 1, 1, stdout)==0 || fflush(stdout))
perror("fwrite from null pointer");
#else
if(write(STDOUT_FILENO, NULL, 1)<0)
perror("write from null pointer");

twitter

Monday, February 15, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts