Re: Structure definitions in XML

Douglas A. Gwyn wrote:
"jacob navia" <jacob@xxxxxxxxxxxxxxxx> wrote in message news:46a0d997$0$25935$ba4acef3@xxxxxxxxxxxxxxxxx
It would be nice if the comitee established a standard
XML format for C structures/definitions.

I assume you're referring to internal binary representations,
or to a raw byte-dump of such into a binary file.

Of course not. I am referring to an XML vocabulary in which
it is standardized how you represent the name of a structure,
and how to add its fields. The standard would allow for an extension
vocabulary if needed, but not include it in the minimal
vocabulary.

Since XML is ASCII, there is no need for any binary representation.

If we have:
<struct>
<Header
<Field-Count="2" <<-- Required field
Scope="2" <<--Required field. Global=0, prototype=1,Local=2,
and higher numbers for higher scopes
TotalSize="12" <<-- optional field
/>
<Fields>
<Field1
Name="f1" <<-- Only required couple of fields
Type="int"
/>
<Field2
Name="f2"
Type="long double"
/>
</struct>

This minimal skeleton would be already useful for browsers,
source code maintainers, and other software that needs to access
the compiler generated information WITHOUT any binary format
precisely.

Since that would necessarily be a platform-specific format,

The committee would ONLY standardize portable stuff (like structure
name, scope and type) and establish a standard way of adding
characteristics to the basic skeleton, so different tools
would read different kinds of information. A debugger would
read the "Address" field, but an IDE would not care about it.

Of course the CONTENT of the extra fields (like address for instance)
would be platform specific, but the way of accessing that
information would be always the same. The committee would JUST specify
the portable content (structure name and the type and name of each
field, and possibly coordinates of the definition, i.e. the
value of __FILE__ and __LINE__ macros)

Other very useful information would be

<Function>
<ReturnType="long double"/>
<Scope="global"/>
<Linkage="extern"
<Arguments="1"/>
<Argument1
Name="a1" <<-- Only required couple of fields
Type="int"
/>

With other adjectives like calling convention, etc possible but
not required.

The basic idea is to make the portable information available
to all XML readers of this information, and to specify a standard
way of enhancing it so that extensions are possible within the framework
without making the core functionality unavailable.

The Standard prescribes that all functions must have a name, a return
type and a list of arguments. All objects have a scope


no "standard format" is possible, and further, it runs counter
to the whole idea of using XML to encapsulate data portably.


I fear you have completely misunderstood the question.

That would allow:
1) debuggers to interoperate using a standard debug information
format.
2) IDEs to interoperate with any compiler
3) Interchange C code between compilers

No, it wouldn't. Do you seriously think that an XML format
for C structures would replace object file formats sich as ELF?


ELF does NOT describe any C structures, excuse me. This is written in
the debug information format, that is either DWARF/COFF/STABS/ or
propietary... DWARF information can be stored in ELF sections,
and XML information would be the same, or it could be stored in
files external to the binaries, and accessible for all.

Note that XML data descriptions have been done for mathematical formula,
music, and many other much more complex data objects than those of
C, that has all objects well defined in the standard...

jacob


.

Relevant Pages

  • Re: ES format
    ... >> runtime format, even a runtime format that is trivially constant, not. ... You aren't allowed by Standard C to define any _external_ linkage ... In particular you certainly can define a 'static' function printf(), ... but otherwise it is part of the language and the compiler ...
    (comp.lang.fortran)
  • Re: next ISO/ANSI standard for C++
    ... > to XML widespread-ness, but mostly to the length of one's career, no? ... 3rd party libraries. ... Wouldn't it be good to just provide a standard ... The more the compiler has to decide, the less probable it is to ...
    (comp.lang.cpp)
  • Re: CFD: XMLification of NOTES
    ... > I do not see any point to invent any other formats in days when XML ... XML is hard to work with in a standard text editor. ... There are clear costs to switching to XML - the format is worse to work ... This was a constraint on WHEN it could be needed to modify the XML file. ...
    (freebsd-arch)
  • Standard and COBOL file formats (was: Report enhancements)
    ... RW> I'd say a Cobol compiler that cannot read a sequential file written ... is using a non-standard file format. ... set up his own file system, which is the standard file system of his ...
    (comp.lang.cobol)
  • Re: COMPATIBILITY
    ... .docx is the format we use. ... Microsoft about moving Word to SGML in 1989, ... XML provides a perfect circuit-breaker to the whole problem. ... XSLTs) implemented in the same standard syntax. ...
    (microsoft.public.mac.office.word)