473,320 Members | 2,189 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

fseek and open_memstream

Why when I uncomment fseek line buf become empty?
#define _GNU_SOURCE
#include <stdio.h>

int main() {
char *buf = 0;
int size = 0;
FILE* f = open_memstream(&buf, &size);
fwrite("test", 1, 4, f);
// fseek(f, 0, SEEK_SET);
fclose(f);
fprintf(stderr, buf);
}
--
Dmitry
Jan 31 '07 #1
23 4140
Dmitry Belous <dm***********@ua.fmwrote:
Why when I uncomment fseek line buf become empty?
#define _GNU_SOURCE
#include <stdio.h>

int main() {
char *buf = 0;
int size = 0;
FILE* f = open_memstream(&buf, &size);
fwrite("test", 1, 4, f);
// fseek(f, 0, SEEK_SET);
fclose(f);
fprintf(stderr, buf);
}
open_memstream() is not an ISO C function. It, or its return value,
probably interacts with fseek() in a way that clears buf, but _why_ this
happens is off-topic here. If it's a POSIX function (I don't know, your
compiler should tell you), ask in comp.unix.programmer. If it's not,
find a newsgroup that deals with your implementation - from the looks of
it, that's gcc, so ask gnu.help.something.

Richard
Jan 31 '07 #2
In article <ep***********@pandora.alkar.net>,
Dmitry Belous <dm***********@ua.fmwrote:
>Why when I uncomment fseek line buf become empty?
>#define _GNU_SOURCE
#include <stdio.h>
>int main() {
char *buf = 0;
int size = 0;
FILE* f = open_memstream(&buf, &size);
What is open_memstream() ? It is not part of C89, and I've never
heard of it being part of C99.
fwrite("test", 1, 4, f);
// fseek(f, 0, SEEK_SET);
fclose(f);
fprintf(stderr, buf);
}
You appear to be using an implementation library function. You
will need to ask in a location that specializes in your implementation.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
Jan 31 '07 #3
On 31 Jan, 16:08, Dmitry Belous <dmitry_bel...@ua.fmwrote:
Why when I uncomment fseek line buf become empty?
#define _GNU_SOURCE
#include <stdio.h>

int main() {
char *buf = 0;
int size = 0;
FILE* f = open_memstream(&buf, &size);
fwrite("test", 1, 4, f);
// fseek(f, 0, SEEK_SET);
fclose(f);
fprintf(stderr, buf);}
<Off-topic>
The non-standard open_memstream() function, from the online man pages
I've viewed, allows you to treat a character buffer as an output
stream to which you can write.

Seeking back to the beginning is presumably regarded as preparation to
write again, so in effect it clears the buffer.

For more information, I suggest you use a GNU libraries newsgroup or
mailing list.
</Off-topic>
Jan 31 '07 #4
In article <11**********************@q2g2000cwa.googlegroups. com>,
<ma**********@pobox.comwrote:
>Seeking back to the beginning is presumably regarded as preparation to
write again, so in effect it clears the buffer.
Or else fclose() causes a null to get written at the current position.

It's possible that you'll get an answer to this on some Linux newsgroup,
but the answer may be "oh, we forgot to specify exactly what happens when
you use fseek() on these extension streams".

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jan 31 '07 #5
Dmitry Belous wrote:
>
Why when I uncomment fseek line buf become empty?
#define _GNU_SOURCE
#include <stdio.h>

int main() {
char *buf = 0;
int size = 0;
FILE* f = open_memstream(&buf, &size);
fwrite("test", 1, 4, f);
// fseek(f, 0, SEEK_SET);
fclose(f);
fprintf(stderr, buf);
}
Who knows? open_memstream is undefined. _GNU_SOURCE is useless
(never referenced). main fails to return a value. If you don't
have a C99 compiler // fseek... is a syntax error.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Jan 31 '07 #6
CBFalconer <cb********@yahoo.comwrites:
Dmitry Belous wrote:
Why when I uncomment fseek line buf become empty?
#define _GNU_SOURCE
#include <stdio.h>

int main() {
char *buf = 0;
int size = 0;
FILE* f = open_memstream(&buf, &size);
fwrite("test", 1, 4, f);
// fseek(f, 0, SEEK_SET);
fclose(f);
fprintf(stderr, buf);
}

Who knows? open_memstream is undefined. _GNU_SOURCE is useless
(never referenced). main fails to return a value. If you don't
have a C99 compiler // fseek... is a syntax error.
On *some* systems, open_memstream is declared in <stdio.hif
_GNU_SOURCE is defined (so _GNU_SOURCE is referenced in <stdio.h>);
since _GNU_SOURCE is in the implementation's namespace, this is
permitted.

// is a syntax error if you have a compiler that implements C90
without extensions; it's accepted by many compilers that don't
implement all of C99. There are cases where // can appear in a legal
C90 program, outside a comment, string literal, or character constant;
if the compiler treats it as a comment delimiter in such cases, it's
not a conforming C90 compiler.

In C99, falling off the end of main() has the effect of "return 0;".

Your overall point, that the code depends on implementation-specific
features and is therefore off-topic, is quite correct, of course.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 1 '07 #7
Keith Thompson wrote:
// is a syntax error if you have a compiler that implements C90
without extensions; it's accepted by many compilers that don't
implement all of C99. There are cases where // can appear in a legal
C90 program, outside a comment, string literal, or character constant;
if the compiler treats it as a comment delimiter in such cases, it's
not a conforming C90 compiler.

In C99, falling off the end of main() has the effect of "return 0;".

Your overall point, that the code depends on implementation-specific
features and is therefore off-topic, is quite correct, of course.
Why do you guys waste so much time on these obviously OS specific code
questions that are not even worth approaching?
Feb 1 '07 #8
Christopher Layne <cl****@com.anodizedwrites:
Keith Thompson wrote:
// is a syntax error if you have a compiler that implements C90
without extensions; it's accepted by many compilers that don't
implement all of C99. There are cases where // can appear in a legal
C90 program, outside a comment, string literal, or character constant;
if the compiler treats it as a comment delimiter in such cases, it's
not a conforming C90 compiler.

In C99, falling off the end of main() has the effect of "return 0;".

Your overall point, that the code depends on implementation-specific
features and is therefore off-topic, is quite correct, of course.

Why do you guys waste so much time on these obviously OS specific code
questions that are not even worth approaching?
I was responding to CBFalconer's followup. Chuck wrote just 3 lines
that, in effect, pointed out that the code is implementation-specific,
hardly a huge waste of time. I wasn't commenting directly on the
original code; I was quibbling about some technical points in Chuck's
followup.

What do you suggest we do instead?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 1 '07 #9
Keith Thompson wrote:
I was responding to CBFalconer's followup. Chuck wrote just 3 lines
that, in effect, pointed out that the code is implementation-specific,
hardly a huge waste of time. I wasn't commenting directly on the
original code; I was quibbling about some technical points in Chuck's
followup.

What do you suggest we do instead?
Well you know I'm not going to tell you what to do Keith. :) It's just that I
see people post such completely random code that it so off-base, yet people
still chase after it like rabid dogs waiting to throw down the corrections.
Why is it?

It's like an attempt to not be an enabler to the OP but with the added message
of "oh and none of this shit is portable either, go to another NG."
Feb 1 '07 #10
Christopher Layne wrote:
Keith Thompson wrote:
>// is a syntax error if you have a compiler that implements C90
without extensions; it's accepted by many compilers that don't
implement all of C99. There are cases where // can appear in a
legal C90 program, outside a comment, string literal, or character
constant; if the compiler treats it as a comment delimiter in such
cases, it's not a conforming C90 compiler.

In C99, falling off the end of main() has the effect of "return 0;".

Your overall point, that the code depends on implementation-specific
features and is therefore off-topic, is quite correct, of course.

Why do you guys waste so much time on these obviously OS specific
code questions that are not even worth approaching?
Because if they are not pointed out, they will have kittens. Soon
we would be knee deep in yowling feral cats and all the birds would
have been eaten.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Feb 1 '07 #11
Christopher Layne <cl****@com.anodizedwrites:
Keith Thompson wrote:
I was responding to CBFalconer's followup. Chuck wrote just 3 lines
that, in effect, pointed out that the code is implementation-specific,
hardly a huge waste of time. I wasn't commenting directly on the
original code; I was quibbling about some technical points in Chuck's
followup.

What do you suggest we do instead?

Well you know I'm not going to tell you what to do Keith. :) It's just that I
see people post such completely random code that it so off-base, yet people
still chase after it like rabid dogs waiting to throw down the corrections.
Why is it?
[...]

Because we like helping people.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 1 '07 #12
CBFalconer wrote:
Because if they are not pointed out, they will have kittens. Soon
we would be knee deep in yowling feral cats and all the birds would
have been eaten.
That's the fear. Yet you need food for kittens to grow.
Feb 1 '07 #13
Keith Thompson wrote:
Because we like helping people.
Hah.

s#helping people#being right#g
Feb 1 '07 #14
Keith Thompson said:

<snip>
I wasn't commenting directly on the
original code; I was quibbling about some technical points in Chuck's
followup.

What do you suggest we do instead?
Well, we *could* get some programming done...

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Feb 1 '07 #15
On 31 Jan, 17:31, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <1170263751.020700.309...@q2g2000cwa.googlegroups. com>,

<mark_blue...@pobox.comwrote:
Seeking back to the beginning is presumably regarded as preparation to
write again, so in effect it clears the buffer.

Or else fclose() causes a null to get written at the current position.
Doh! Of course...

Feb 1 '07 #16
Christopher Layne <cl****@com.anodizedwrites:
Keith Thompson wrote:
Because we like helping people.

Hah.

s#helping people#being right#g
The two are not incompatible.

This is boring. Bye.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 1 '07 #17
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
....
>Why is it?
[...]

Because we like helping people.
Translation: Because we have no lives.

Feb 1 '07 #18
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
....
>I was responding to CBFalconer's followup. Chuck wrote just 3 lines
that, in effect, pointed out that the code is implementation-specific,
hardly a huge waste of time. I wasn't commenting directly on the
original code; I was quibbling about some technical points in Chuck's
followup.

What do you suggest we do instead?
Just ignore it. (As you *claim* to do with the "trolls")
The idea is, if it is effective there, then it should be so here.

Feb 1 '07 #19
Christopher Layne <cl****@com.anodizedwrites:
Keith Thompson wrote:
>I was responding to CBFalconer's followup. Chuck wrote just 3 lines
that, in effect, pointed out that the code is implementation-specific,
hardly a huge waste of time. I wasn't commenting directly on the
original code; I was quibbling about some technical points in Chuck's
followup.

What do you suggest we do instead?

Well you know I'm not going to tell you what to do Keith. :) It's just that I
see people post such completely random code that it so off-base, yet people
still chase after it like rabid dogs waiting to throw down the corrections.
Why is it?

It's like an attempt to not be an enabler to the OP but with the added message
of "oh and none of this shit is portable either, go to another NG."
It is the biggest "put off" in this NG IMO. A bunch of show offs rushing
to be first to post the "standard correction". Often they post the
correction even though they can see it has been done 20 times already.

Tedious and mind numbingly petty isn't sufficient to describe the
characters of certain contributors to this NG.

Again : if you don't want to be constructive and help, then don't reply.
Feb 2 '07 #20
Richard <rg****@gmail.comwrites:
[...]
Again : if you don't want to be constructive and help, then don't reply.
Correcting errors is constructive.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 2 '07 #21
Richard said:

<snip>
Again : if you don't want to be constructive and help, then don't reply.
When you've posted a large volume of constructive, helpful replies on C
programming, maybe - just *maybe* - I'll start taking an interest in your
netiquette suggestions. Until then, if you can't be constructive and
helpful, don't expect me to treat you seriously.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Feb 2 '07 #22
In article <s5******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>Richard said:

<snip>
>Again : if you don't want to be constructive and help, then don't reply.

When you've posted a large volume of constructive, helpful replies on C
programming, maybe - just *maybe* - I'll start taking an interest in your
netiquette suggestions. Until then, if you can't be constructive and
helpful, don't expect me to treat you seriously.
Oh God. The irony...

Feb 2 '07 #23
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>Richard <rg****@gmail.comwrites:
[...]
>Again : if you don't want to be constructive and help, then don't reply.

Correcting errors is constructive.
No, its not.

(Except for this one, of course)

Feb 2 '07 #24

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

62
by: Christopher Benson-Manica | last post by:
On thinking about the "replace a word in a file" thread, I wondered how easy it would be to accomplish the same thing with only one file pointer. This led me to some questions... "For a text...
15
by: TJ Walls | last post by:
Hello All, I am baffled ... I am trying to improve the speed of a program that I have written that performs random access within a file. It relies heavily on fseek and is very slow. To test, I...
10
by: Orion | last post by:
Hey, I was wondering if it was possible to determine if you hit 'EOF' using fseek? I'm using fseek to traverse through the file from start to end and capturing the data into a linked list...
2
by: cedarson | last post by:
I am writing a program and have been instructeed to use the 'fseek', 'ftell', and 'stat' functions, however, after looking in the online manual for each of these, I am still unsure on how to use...
10
by: Kenneth Brody | last post by:
I recently ran into an "issue" related to text files and ftell/fseek, and I'd like to know if it's a bug, or simply an annoying, but still conforming, implementation. The platform is Windows,...
3
by: Chen ShuSheng | last post by:
HI, I am now study a segment of codes: ------------------------ printf("%p\t",fp); /*add by me*/ fseek(fp, 0L, SEEK_END); /* go to end of file */ printf("%p\t",fp); ...
6
by: ericunfuk | last post by:
A basic question: When the documentation says "fseek() clears EOF indecator, does it mean when you seek over EOF, EOF is no longer at the original position and hence removed?Say, after I seek...
6
by: ericunfuk | last post by:
I have posted a few other posts before this one today, I still can't solve my problem, I think I need to elaborate my problem now. I'm trying to send a file using UDP, below is a segment of my...
20
by: ericunfuk | last post by:
If fseek() always clears EOF, is there a way for me to fread() from an offset of a file and still be able to detect EOF?i.e. withouting using fseek(). I also need to seek to an offset in the file...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.