How to obtain/implement the position (line and column) from Json-source-file

[Omar-Medina]

Hello dear Team Json ,

First. Thanks very much for the library.

Second. according to the already existing "Q&A" looks like, that it is not possible to obtain/read/get the current position (line and column) from Json-source-file while the SAX-parse is being used.

But it looks, that the information is available.

Question:
Can you please indicate , where is the best place in the json--nlohmann-library to add the implementation of the providing the current position (line and column) from Json-source-file while the SAX-parse is being used.

I am thinking about to extend the SAX interface json_sax_t with one API to set the current position (line and column) from Json-source-file while the SAX-parse is being used and before the call-backs are called, so that , when one of the callbacks is called, then the information is available

json-lib parses sorce file -> json-lib sets the position from sorce file -> json-lib calls one SAX-callbacks

[nlohmann]

This is currently not possible in the SAX interface. We are currently working on #4585 which will use the information collected with JSON_DIAGNOSTIC_POSITION to create better exception messages. However, the position information is currently only available for JSON values parsed with the parse function - not sax_parse.

I think there is no way to get these information in the SAX parser without making several changes to the SAX interface.

[gregmarr]

The lexer has that information, but it doesn't look like there is a good way to get a pointer to the lexer from the SAX interface. I was thinking that if the InputAdapter tracked this information, and the SAX object knew about the InputAdapter that might work. The InputAdapter would hopefully just need to do this:

json/include/nlohmann/detail/input/lexer.hpp

Lines 1341 to 1368 in 2d42229

	char_int_type get()
	{
	++position.chars_read_total;
	++position.chars_read_current_line;
	if (next_unget)
	{
	// just reset the next_unget variable and work with current
	next_unget = false;
	}
	else
	{
	current = ia.get_character();
	}
	if (JSON_HEDLEY_LIKELY(current != char_traits<char_type>::eof()))
	{
	token_string.push_back(char_traits<char_type>::to_char_type(current));
	}
	if (current == '\n')
	{
	++position.lines_read;
	position.chars_read_current_line = 0;
	}
	return current;
	}

There is no sax_parse right now that takes an existing InputAdapter and a SAX object, so that would need to be added, but at least it wouldn't need any changes to json_sax.

Another issue is that the parser takes the InputAdapter by value, so the InputAdapter would need to wrap a shared object that stores that state, it can't be stored in the InputAdapter itself.

[Omar-Medina]

Hello everyone,
Thanks for the answers.
just a commentator in all modesty from my side :

1. The position shall not depend on define JSON_DIAGNOSTIC_POSITION
   Reason:
   Since the provided callbacks called by the sax_parse shall return "true" to continue with the parsing AND they shall return "false" to stop the parse. then here is interesting in case of returning "false" to provide information about the position. For example this information shall be used by the user to check an invalid data in the JSON-object .

2. During debuging the library , I was observing in the callstack, that the callbacks are called from sax_parse_internal in file parser.hpp line 180. At this function, the function m_lexer.get_position() is available in all cases.
   Question . Why is it not possible to call (for example) before the line "if (JSON_HEDLEY_UNLIKELY(!sax->key(m_lexer.get_string())))" (line=219) one new function "sax->SetPosition(get_position())". The new function SetPosition() provides the position.
   The new function can be added in all cases.

Thanks in advance for your reply.
Omar

[nlohmann]

1. You are right - the positions are always available to the lever, but only with JSON_DIAGNOSTIC_POSITION they are stored in the JSON value. I have not understood your point on the SAX return values.
2. Of course, the SAX interface can be extended. But this would be a breaking change for existing clients.