Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: When parameters to printf are in memory |
| Date | 2016-10-01 09:32 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <nsnsab$ps7$1@dont-email.me> (permalink) |
| References | <nsjbgn$o4k$1@dont-email.me> <nsje01$1ma$1@dont-email.me> <nsll9t$f0q$1@news.xmission.com> <nsmd2o$52a$1@dont-email.me> <4c9d5fe4-9f6f-46ec-92ff-1da78b41e836@googlegroups.com> |
On 01/10/2016 07:18, Malcolm McLean wrote: > On Friday, September 30, 2016 at 8:06:20 PM UTC+1, James Harris wrote: >> >> The problem in this case is to store data about exceptions. It seems >> practical to have an exception made up of >> >> an identifier for the exception's type >> parameters >> >> The exception would have an associated string which would be printed if >> a stack trace is generated. The parameters are any values which are >> relevant to the exception and could be referred to from within the string. >> >> So it's not an academic query. The issue is to render the string with >> values filled in. >> > So fundamentally you need a structure like this > > formatstring (eg "%s%p%d") > parameters eg asciiz string, undereferenceable memory address, 32 bit integer Yes, but also with some text among the placeholders. Such a string would be a human-language description and the parameters would provide specifics. In the future the message string could come from a table which was keyed on message id and human language so that the exception report could be rendered in French, Swahili etc. But for now I'll settle for English. > thinking of it like that, the problem is a straightforwards one > of rearranging data. Thinking of it in terms of higher-level > language constructs, it becomes intractable. > > And you can't unfortunately use printf, because it has been specified > in terms of higher level constructs rather than to operate on > bits. But it's easy enough to implement, especially if you don't > need field width and precision. I was trying to take an easy course but that turns out not to be feasible. I will need to do it properly! What I should really do is provide /named/ parameters. Then they can appear in the message text under their names rather than being positional. E.g. "Division failure trying to divide $(numerator) by $(denominator)" Using names would make the message text more recognisable. It would allow parameters to be printed in a different order in different human languages. And it would allow a given parameter to be printed more than once, perhaps in both decimal and hex. This is a lot of work though. And this was only to support the real program I was writing. Aargh! ;-) -- James Harris
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 16:20 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 16:43 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-29 20:30 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 21:23 +0100
Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-09-29 22:03 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 22:35 +0100
Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-09-29 23:11 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-30 19:53 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 20:53 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-01 09:08 +0100
Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-10-01 11:15 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 08:32 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 11:15 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 08:28 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 09:49 +0100
Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-10-04 11:43 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 13:42 +0100
Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-10-04 14:03 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 14:16 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 20:01 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 20:24 +0100
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 20:40 +0100
Re: When parameters to printf are in memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-04 22:51 +0100
Re: When parameters to printf are in memory "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-04 14:25 -0400
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 20:31 +0100
Re: When parameters to printf are in memory BartC <bc@freeuk.com> - 2016-09-29 17:03 +0100
Re: When parameters to printf are in memory gazelle@shell.xmission.com (Kenny McCormack) - 2016-09-30 12:20 +0000
Re: When parameters to printf are in memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-30 05:55 -0700
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-30 20:06 +0100
Re: When parameters to printf are in memory gazelle@shell.xmission.com (Kenny McCormack) - 2016-09-30 22:01 +0000
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-01 09:15 +0100
Re: When parameters to printf are in memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-30 23:18 -0700
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-01 09:32 +0100
Re: When parameters to printf are in memory jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-29 18:35 +0200
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 19:55 +0100
Re: When parameters to printf are in memory jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-29 21:22 +0200
Re: When parameters to printf are in memory Barry Schwarz <schwarzb@dqel.com> - 2016-09-29 11:20 -0700
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-09-29 20:08 +0100
Re: When parameters to printf are in memory Lőrinczy Zsigmond <nospam@for.me> - 2016-10-02 20:15 +0200
Re: When parameters to printf are in memory Lőrinczy Zsigmond <nospam@for.me> - 2016-10-02 20:19 +0200
Re: When parameters to printf are in memory gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-02 18:29 +0000
Re: When parameters to printf are in memory Lőrinczy Zsigmond <nospam@for.me> - 2016-10-03 07:04 +0200
Re: When parameters to printf are in memory James Harris <james.harris.1@gmail.com> - 2016-10-04 08:36 +0100
Re: When parameters to printf are in memory jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-02 21:27 +0200
csiph-web