473,854 Members | 1,453 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Asking if elements in struct arre zero

If I have:

struct one_{
unsigned int one_1;
unsigned short one_2;
unsigned short one_3;
};

struct two_{
unsigned int two_1;
unsigned short two_2;
unsigned char two_3;
};

struct mystruct{
struct one_ one;
struct two_ two;
}mystruct1;

Then could I by any change ask on the value of the whole struct mystruct1,
that is all the elements in the struct in one call? I want to do something
like (in pseudo like language):

if(mystruct1 == 0) { print("All elements of mystruct1 is zero");}
Best Regards
Terry
Nov 13 '05
258 8877
Richard Heathfield <do******@addre ss.co.uk.invali d> wrote in message news:<bp******* ***@sparta.btin ternet.com>...
Programmer Dude wrote:
Richard Heathfield wrote:
...because providing newbies with the power to post HTML into
comp.lang.c without also providing them with the wisdom not to
is not a sign of advancement, but of poverty of thought.


No, that's just your *opinion* based on your desire for a TTY text
environment.


No, it's my opinion based on my desire for a low threshold for
interoperabilit y. When I write a letter for immediate printing and posting,
I use a word processor (Lotus WordPro, if you care), with proportional
fonts, italics, colour, or whatever seems appropriate. But when I send
information to someone, I want to maximise their chance of reading it
swiftly and efficiently, without having to dig out some special software or
having to switch to a different OS. I don't send people WordPro docs unless
I know for sure that they use WordPro as their word processor of choice
(and I'm the only one I know who uses it!) Text is just about the most
portable form of computer communication there is, so I think it makes sense
for everyone to use it when interfacing with each other, except when *all*
parties to a communication agree to use some other format that (by accident
or design) they can all access.


I use Word Pro (96 edition) now and then! And it used to be
considered such a resource hog...........

on text, generally agree, i sometimes get work related email saying,
essentially, read this [attached] pdf! The pdf is a letter or
somesuch, perfectly formatted, nice logos etc - completely unreadable
if i don't have a pdf reader, and i need to go through the bother of
launching it too (and frequently resizing onscreen to read it!)

I always prefer the seperation of message (just plain text) and other
stuff (image, design, 'officialdom' etc) into an attachment itself
fairly standards compliant (so i can be confident that i can see it
without using some exclusive software).

In discussion newsgroups there's specifically no need for attachments
and this plain text is the natural default with broadest reach.
Nov 13 '05 #221
Richard Heathfield wrote:
...your *opinion* based on your desire for a TTY text environment.
No, it's my opinion based on my desire for a low threshold for
interoperabilit y.


Same thing. You stated it in terms of the goal; I stated it in terms
of the mechanism.

However, if you truly mean it exactly as written, I assume you would
be open to formatted text if it became as ubiquitous as TTY text, for
it would then achieve your stated goal.
When I write a letter for immediate printing and posting, I use a
word processor (Lotus WordPro, if you care), with proportional
fonts, italics, colour, or whatever seems appropriate.
So you recognize the usefulness of formatted text.
...I think it makes sense for everyone to use [TTY text] when
interfacing with each other, except when *all* parties to a
communication agree to use some other format that (by accident
or design) they can all access.


And, in fact, I agree. My feeling, as I have said, is that a time
is coming when something (probably HTML) *will* be a default tool
that everyone has access to.
Isn't the point avoiding advanced features not supported by all?


The point is to maximise communication by minimising barriers to
communication.


Then it would seem another solution is to provide those advanced
features to everyone. That removes the barriers AND allows for
the increased utility of formatted text (which it appears we agree
is useful).

I don't agree those are the only choices.

But you don't get to choose other people's actions for them,..


??? The reply doesn't seem to connect to the quoted bit at all.


You say that there are more choices than the two I presented. But
you don't have control over the choices people make. In practice,
the two I outlined are, IMHO, the most likely....


"Most likely". In other words, there ARE more than two. That
people may self-select the possibles down to two is another matter.

More importantly (from my POV), if people have narrowed options
due to habit, tradition, ignorance or stubbornness, it's good to
introduce a dialog for change once in a while. Even if the result
of the dialog is, "Not yet" (or "Over my dead body!" :-), at least
the issue gets aired and--hopefully--genuinely considered.

Peas Out.

--
|_ CJSonnack <Ch***@Sonnack. com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ _______________ ____| Call: 1-800-DEV-NULL |
|______________ _______________ _______________ _|_____________ __________|
Nov 13 '05 #222
Programmer Dude wrote:
Richard Heathfield wrote:
...your *opinion* based on your desire for a TTY text environment.
No, it's my opinion based on my desire for a low threshold for
interoperabilit y.


Same thing. You stated it in terms of the goal; I stated it in terms
of the mechanism.


True enough. But it's the goal that counts.
However, if you truly mean it exactly as written, I assume you would
be open to formatted text if it became as ubiquitous as TTY text, for
it would then achieve your stated goal.
The problem is that, by its very nature, formatted text is considerably more
painful to process than plain text. For example, consider utilities such as
grep. Such utilities, which are very powerful tools for information
processing, work much better with plain text than with formatted text.
When I write a letter for immediate printing and posting, I use a
word processor (Lotus WordPro, if you care), with proportional
fonts, italics, colour, or whatever seems appropriate.


So you recognize the usefulness of formatted text.


In non-electronic form? Sure. I have no problem with printed documents being
formatted nicely, because there's no downside (other than OCR difficulties
- but if I send someone information that they then decide they would prefer
to have electronically, all they have to do is ask, and I can send them an
electronic version). I also have no problem with HTML on, say, a Web site.
(That, after all, is what HTML is /for/.)
...I think it makes sense for everyone to use [TTY text] when
interfacing with each other, except when *all* parties to a
communication agree to use some other format that (by accident
or design) they can all access.


And, in fact, I agree. My feeling, as I have said, is that a time
is coming when something (probably HTML) *will* be a default tool
that everyone has access to.


It will need to be paralleled by global accessibility to text processing
tools that can do for (say) HTML what (say) grep does for plain text.
Isn't the point avoiding advanced features not supported by all?


The point is to maximise communication by minimising barriers to
communication.


Then it would seem another solution is to provide those advanced
features to everyone. That removes the barriers AND allows for
the increased utility of formatted text (which it appears we agree
is useful).


I agree that it's useful for printed matter. Usenet is not a print medium.
> I don't agree those are the only choices.

But you don't get to choose other people's actions for them,..

??? The reply doesn't seem to connect to the quoted bit at all.


You say that there are more choices than the two I presented. But
you don't have control over the choices people make. In practice,
the two I outlined are, IMHO, the most likely....


"Most likely". In other words, there ARE more than two. That
people may self-select the possibles down to two is another matter.


No, it's the matter at hand. I'm talking about reality, not mere
possibilities.
More importantly (from my POV), if people have narrowed options
due to habit, tradition, ignorance or stubbornness, it's good to
introduce a dialog for change once in a while. Even if the result
of the dialog is, "Not yet" (or "Over my dead body!" :-), at least
the issue gets aired and--hopefully--genuinely considered.


Well, there's no harm in dialog, as long as everyone stays cool.

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #223
Richard Heathfield wrote:
And, in fact, I agree. My feeling, as I have said, is that a time
is coming when something (probably HTML) *will* be a default tool
that everyone has access to.


It will need to be paralleled by global accessibility to text
processing tools that can do for (say) HTML what (say) grep does
for plain text.


Agreed. Text *became* a universal medium. I'm thinking/guessing
HTML (or something like it) will *become* a universal medium.

When I remember how fast the web grew (it wasn't all THAT long ago
I was playing with this weird new thing, called "Mosaic", that mixed
formatted text and graphics on "the World Wide Web"...and thought
to myself, "This will never fly. Too slow. Too silly. Who needs
it?"), and when I observe how fast modern developments spread to
the corners of the world, and when I see how much HTML email I get,
and when I see the *need* to fight it off in amUSENET,.... well, I
can't help but wonder if TTY text's days are numbered.

And with not very big numbers, either! ;-\

--
|_ CJSonnack <Ch***@Sonnack. com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ _______________ ____| Call: 1-800-DEV-NULL |
|______________ _______________ _______________ _|_____________ __________|
Nov 13 '05 #224
Programmer Dude <Ch***@Sonnack. com> wrote in
news:3F******** *******@Sonnack .com:
Richard Heathfield wrote:
And, in fact, I agree. My feeling, as I have said, is that a time
is coming when something (probably HTML) *will* be a default tool
that everyone has access to.
It will need to be paralleled by global accessibility to text
processing tools that can do for (say) HTML what (say) grep does
for plain text.


Agreed. Text *became* a universal medium. I'm thinking/guessing
HTML (or something like it) will *become* a universal medium.


I don't know about text 'becoming' a universal medium. Certainly for all
of my life it /is/ the universal medium.

HTML is merely another expression of text, with tags, to say how it
should be 'marked up'. If you want to, you can also include CSS into HTML
since they're so tied together... in which case HTML becomes text with
tags to say how it should be marked up and an external file to say how it
should be rendered. Ultimately, however, it's still text.

Whether it's an HTML email or an XHTML usnet message, the majority of the
useful context (unless you're in one of the binaries.erotic a groups) is
still text. Why use HTML to format text when text is already easilly
formatted in not-HTML?

Anyone who says a picture is worth 1,000 words doesn't have enough
imagination... :)
When I remember how fast the web grew (it wasn't all THAT long ago
I was playing with this weird new thing, called "Mosaic", that mixed
formatted text and graphics on "the World Wide Web"...and thought
to myself, "This will never fly. Too slow. Too silly. Who needs
it?"), and when I observe how fast modern developments spread to
the corners of the world, and when I see how much HTML email I get,
and when I see the *need* to fight it off in amUSENET,.... well, I
can't help but wonder if TTY text's days are numbered.

And with not very big numbers, either! ;-\


There's no way in hell you can eliminate the TTY, at least not until
corporations rule the world entirely.

Just look at what you can do on a text console which /cannot/ be done in
GUI land! The GUI people have been harping on for at least since I did
user-interface design in uni about how hard it is to /allow/ complex
tasks. I can easilly, for example, find all the header files in a
directory (recursively), except backups, put them through a document
processor and make both LaTeX and HTML documentation, compile it and run
test programs against the compiled version.

And I can do it without using any software other than a makefile.

The TTY is far from dead.

Ian Woods

Nov 13 '05 #225
[snips]

On Tue, 11 Nov 2003 20:23:50 +0000, Keith Thompson wrote:
We've seen a major transition of e-mail from a medium that only
supported plain text to one that also supports HTML. We simply are
not seeing any signs of a similar transition for Usenet, though the
idea has been under discussion for years. Usenet has evolved
mechanisms for transferring binary files, but there just hasn't been
any significant demand for HTML. If this transition is inevitable,
why hasn't it started?


It has. Thing is, every time it gets going, the old guard jumps in with
their "We must preserve the sanctity of Usenet" bit and it stops again.

If the old guard stopped screaming every time they saw an HTML post, you'd
very soon see HTML posts regularly. Whether this is a good thing or a
desirable thing may be open to question.
Nov 13 '05 #226
Programmer Dude wrote:
Richard Heathfield wrote:
And, in fact, I agree. My feeling, as I have said, is that a time
is coming when something (probably HTML) *will* be a default tool
that everyone has access to.
It will need to be paralleled by global accessibility to text
processing tools that can do for (say) HTML what (say) grep does
for plain text.


Agreed. Text *became* a universal medium.


Yes, it did.
I'm thinking/guessing
HTML (or something like it) will *become* a universal medium.


I don't think it will become universal as long as programmers are around,
because the sheer flexibility that text gives you is hard to beat. But when
we've all programmed ourselves out of a job? Well, at that point, maybe
you'll be right. But at that point we probably won't need comp.lang.c any
more, either.

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #227
On Fri, 14 Nov 2003 21:13:09 +0000 (UTC),
Richard Heathfield <do******@addre ss.co.uk.invali d> wrote:

It will need to be paralleled by global accessibility to text processing
tools that can do for (say) HTML what (say) grep does for plain text.

The only HTML email I receive is spam where the HTML has been used to
trick spam filters. v<!--important-->i<!--message-->a etc.

i.e. HTML has been chosen because it stops tools like grep working.

"Fixing" grep would be a nightmare.
grep --content
grep --tags
grep --nocomments

And then what do you do with malformed HTML? The beauty of plain text is
that it cannot be malformed. It can be gibberish but in general people don't
disagree with what it says. But people do disagree with what HTML says
(or looks like) which is why so many websites just don't work except with
IE at 800x600.

Tim.

--
God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.

http://tjw.hn.org/ http://www.locofungus.btinternet.co.uk/
Nov 13 '05 #228
Tim Woodall wrote:
On Fri, 14 Nov 2003 21:13:09 +0000 (UTC),
Richard Heathfield <do******@addre ss.co.uk.invali d> wrote:

It will need to be paralleled by global accessibility to text processing
tools that can do for (say) HTML what (say) grep does for plain text.
The only HTML email I receive is spam where the HTML has been used to
trick spam filters. v<!--important-->i<!--message-->a etc.

i.e. HTML has been chosen because it stops tools like grep working.


Quite.

"Fixing" grep would be a nightmare.


On the contrary. All we have to do is find a programmer who advocates HTML
as a valid universal format, and ask him to produce an HTML-aware version
of grep.

And then we get to test it! ;-)

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #229
>Tim Woodall wrote:
The only HTML email I receive is spam where the HTML has been used to
trick spam filters. v<!--important-->i<!--message-->a etc.

i.e. HTML has been chosen because it stops tools like grep working.
In article <bp**********@s parta.btinterne t.com>
Richard Heathfield <bi****@eton.po wernet.co.uk> writes:
Quite. "Fixing" grep would be a nightmare.

On the contrary. All we have to do is find a programmer who advocates HTML
as a valid universal format, and ask him to produce an HTML-aware version
of grep.


If one's only goal is to test for spam, there is an easier method:
just remove (or separate out) the HTML tags.

There are two ways to go about this; one works better than another.
The "dumb" way is to split an input into two outputs based only
on the "<" and ">" characters:

/*
* Copy input from "in" to "txt" and "tag" output files.
* Text in <angle brackets> goes to the "tag" file, the
* rest goes to the "txt" file.
*/
int separate(FILE *in, FILE *txt, FILE *tag) {
int c;
int in_tag = 0, next_tag;

while ((c = getc(in)) != EOF) {
next_tag = in_tag;
if (c == '<')
in_tag = 1;
else if (c == '>')
next_tag = 0;
putc(c, in_tag ? tag : txt);
in_tag = next_tag;
}
}

The "smart" way is to process the HTML and recognize the parts
of text that browser-type readers discard. This works better
for spam-detection, because some spammers have switched from:

s<!--junk>pamkeyword

to something more like:

s<script language="unkno wn">junk</script>pamkeywo rd

The spammers are doing this because people are stripping HTML
comments before feeding text to spam-detectors.

(None of this really addresses the fundamental problem, which is
the fact that spam is theft. As long as the spammer's ill-gotten
profits exceed his or her cost and risk, the spammer comes out
ahead on average. Since the cost and risk is miniscule -- especially
with spammers hijacking Windows-based boxes to send the actual spam
-- the required "per-spam profit" is likewise miniscule. The only
real solution is to raise the cost of spamming, either directly
[e.g., in dollars] or indirectly [e.g., by jailing the thieves for
their hijacking of cable-connected home PCs]. This will not make
the spam stop completely, but will reduce it to manageable levels.
Content-filtering is an attempt to increase the cost, but because
spammers *are* thieves, the increased costs are mainly borne by
those being stolen from, rather than the spammers.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #230

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

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.