i try to read out information from a file. there will be sometime within the read information a charendterminator. is there a possibilty to ignore this and step to the next character?
long lReadBytes = 0; size_t t = 100; char *buffer = (char *) malloc(sizeof(char*)); buffer = NULL;
while ( (lReadBytes = getline( &buffer, &t, pdfstream)) > 0 ) { int pos = 0; for (pos = 0; pos <= lReadBytes; pos++) { printf("%c\n", buffer[pos]); } }
thanks. -- comp.lang.c.moderated - moderation address: c...@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.
sebastian <cup...@gmx.de> writes: > i try to read out information from a file. there will be sometime > within the read information a charendterminator. is there a possibilty > to ignore this and step to the next character?
> gcc options
> Target: x86_64-linux-gnu > Configured with: [snip] > input line
> T^@e^@s^@t
That looks like text encoded with UTF-16. Ignoring the null characters might work if all the represented characters are in the range 0..255, but you'd be better off either converting it to another form or figuring out how to read it as UTF-16 (which includes getting the endianness right).
> code example
> long lReadBytes = 0; > size_t t = 100; > char *buffer = (char *) malloc(sizeof(char*));
The cast is unnecessary and potentially harmful.
Why are you allocating sizeof(char*) bytes? If getline() works the way I think it does, the number of bytes in the initial allocation probably doesn't matter (for that matter, I think you can start with a null pointer), but allocationg sizeof(char*) bytes for a char array doesn't make sense.
If you want to ignore null characters, just ignore them:
if (buffer[pos] != '\0') { /* whatever */ }
> } > }
-- 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" -- comp.lang.c.moderated - moderation address: c...@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.
> i try to read out information from a file. there will be sometime > within the read information a charendterminator. is there a possibilty > to ignore this and step to the next character?
Show us a complete, compilable program. -- Fred K -- comp.lang.c.moderated - moderation address: c...@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.
On Thu, 5 May 2011 11:35:24 -0500 (CDT), sebastian <cup...@gmx.de> wrote:
>Hello,
>i try to read out information from a file. there will be sometime >within the read information a charendterminator. is there a possibilty >to ignore this and step to the next character?
The standard string functions will stop processing data a the first '\0'. However, in code you write, you are free to do whatever you want when you encounter such a character. You do need to make sure that you have some other way of determining the end of the data since you are not following string conventions.
-- Remove del for email -- comp.lang.c.moderated - moderation address: c...@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.
-- ⚂⚃ 100% natural -- comp.lang.c.moderated - moderation address: c...@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.
> pointers are atleast 2 bytes in size, according to the standard > (8 in this specific case).
In comp.lang.c.moderated, unless otherwise specified, "the standard" normally refers to the C standard, which imposes no such requirement. I presume you're referring to some other standard? -- James Kuyper -- comp.lang.c.moderated - moderation address: c...@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.
sebastian <cup...@gmx.de> writes: > i try to read out information from a file. there will be sometime > within the read information a charendterminator. is there a possibilty > to ignore this and step to the next character?
Why malloc? You need a char *, and buffer is already a char *.
Furthermore, a foo * is a pointer to a foo or to an array of foo, so the size passed to malloc() should be a multiple of the sizeof(foo). It just so happens that *everything* is a multiple of sizeof(char), but this assignment is still a conceptual mistake.
Here is a common malloc() idiom:
foo *p = malloc(n * sizeof(*p));
This is particularly useful if p is declared somewhere else, e.g.
foo *p;
/* 100 lines of code */
p = malloc(n * sizeof(*p));
because you do not need to change the malloc() call (which is easy to forget) if you decide to change the type of p.
> buffer = NULL;
The memory you malloc()ed is orphaned here, so the (incorrect) malloc() call is completely wasted.
On the first iteration, since buffer is NULL, the value of t is not used; a new buffer is allocated, and its size is stored in t. Thus, there is no need to initialize t. It is generally not a good idea to initialize a variable to a non-zero value unless the initial value is actually used, as it may give the reader the impression that the value is meaningful and cause him to waste time trying to figure out where it is used. In this piece of code, the only initialization needed is that of buffer to NULL.
BTW, you should free(buffer) after the loop.
DES -- Dag-Erling Smørgrav - d...@des.no -- comp.lang.c.moderated - moderation address: c...@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.
> pointers are atleast 2 bytes in size, according to the standard > (8 in this specific case).
Since when? In C a byte is equivalent to a char and is not necessarily an octet. There are systems where a char occupies 32 bits and that means that within the de3finitions of Standard C, a byte is 32 bits. Yes, I know that conflicts with the wider use of the term and the common (mis)understanding that a byte is 8 bits.
The only guarantee is that the sizeof a char* is at least 1 and that the range of values it can hold is at least (IIRC) 32768.
>>> while ( (lReadBytes = getline(&buffer,&t, pdfstream))> 0 )
I cannot comment on whether that is an Open Group extension but it is part of the C++ standard library (and yes, I know that C++ is not C)
-- comp.lang.c.moderated - moderation address: c...@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.
> pointers are atleast 2 bytes in size, according to the standard > (8 in this specific case).
[...]
There is no requirement in the standard that pointers must be at least 2 bytes. The requirement for support of objects of at least 65535 bytes, along with the fact that each byte of an object has a distinct address, does imply that pointers must be at least 16 bits (for hosted implementations), but a byte can be bigger than 8 bits.
-- 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" -- comp.lang.c.moderated - moderation address: c...@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.
-- Kenneth Brody -- comp.lang.c.moderated - moderation address: c...@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.
>pointers are atleast 2 bytes in size, according to the standard
Where do you think the standard specifies the byte size of a pointer? And why do you think a byte is always 8 bits?
>(8 in this specific case).
And you know this because?
-- Remove del for email -- comp.lang.c.moderated - moderation address: c...@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.
> I cannot comment on whether that is an Open Group extension but it is > part of the C++ standard library (and yes, I know that C++ is not C)
The C++ standard library does have a getline() function (actually several of them, I think), but that's not the same as the Open Group getline() function. (The C++ version, because of namespaces and overloading, doesn't intrude on the user namespace.)
-- 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" -- comp.lang.c.moderated - moderation address: c...@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.
>>pointers are atleast 2 bytes in size, according to the standard
> Where do you think the standard specifies the byte size of a pointer? > And why do you think a byte is always 8 bits?
I seem to recall somwhere a lower limit on pointer range is given that's greater than can fit in 8 bits, I had forgotten that the c standard allows for bytes of unusual size.
>>(8 in this specific case).
> And you know this because?
I have a passing familiarity with the compiler mentioned in the original post.
> -- > Remove del for email
-- ⚂⚃ 100% natural -- comp.lang.c.moderated - moderation address: c...@plethora.net -- you must have an appropriate newsgroups line in your header for your mail to be seen, or the newsgroup name in square brackets in the subject line. Sorry.